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ABSTRACT 



A hierarchical communication network management system 
is structured by a plurality of agents and sub-managers 
connected to lower communication networks and an inte- 
gration manager connected to a higher communication net- 
work. Each of the sub-managers functions as an agent to the 
integration manager and functions as a manager to each 
agent, so that it becomes possible to employ a Simple 
Network Management Protocol (SNMP) between each 
agent and its sub-manager and between a sub-manager and 
the integration manager. 
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FIG.4 



SUBMANAGER-MIB-EXAMPLE DEFINITIONS : : = BEGIN 

IMPORTS i 
enterprises, NetworkAddress, IpAddress, Counter, Gauge, TimeTicks 

FROM RFC1155-SMI 
OBJECT-TYPE 

FROM RFC-1212 
DlsplayString, IfEntry, AtEntry, IpAddrEntry, IpRouteEntry, 
IpNefroMediaEntry, PhysAddress, TcpConnEntry, UdpEntry, EgpNeighEntry 

FROM RFC1 21 3-MIB 
TRAP-TYPE 

FROM RFC-1215; 

hltachl OBJECT IDENTIFIER :: = {enterprises 116} 
systemExMlb OBJECT IDENTIFIER : : = { hltachl 5 } 
hiuxwe2 OBJECT IDENTIFIER : : = { systemExMib 5 } 
cometMibs OBJECT IDENTIFIER :: = {hiuxwe2 1} 
hierarchy OBJECT IDENTIFIER : : = { cometMibs 4 } 
standard OBJECT IDENTIFIER : : = { hierarchy 1 } 
extension OBJECT IDENTIFIER : : = { hierarchy 2 } 
smgTotal OBJECT IDENTIFIER : : = { standard 1 } 
smglpNode OBJECT IDENTIFIER : : = { standard 2 } 

smgSumTcp OBJECT IDENTIFIER : : = { extension 1 } 

- SUB-MANAGER PERIODICAL COLLECTION MIB GROUP 
(The Submanager Collection group) ^ 

- STRUCTURED BY THE SUB-MANAGER TOTAL GROUP AND THE 
SUB-MANAGER IP NODE GROUP 

- SUB-MANAGER TOTAL GROUP 
( the Submanager Total group ) 

smgTotalManagedNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF IP NODE FOR MANAGEMENT 
: : = { smgTotal 1 } 

smgTotalCriticalNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF NODE WHICH IS CRITICAL WITH 
THE SUB-MANAGER " 
: : = { smgTotal 2 } 
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FIG.5 

smgTotalMarginalNodeNumber OBJECT-TYPE 

syntax Integer ( 0..65535 ) 

ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF NODES IN WHICH THERE IS A TCP 
/ IP INTERFACE WHICH CAN COMMUNICATE WITH THE SUB- 
MANAGER BUT WHICH ARE NOT OPERATING " 
: : = { smgTotal 3 } 

smgTotalNormalNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE NUMBER OF NODES IN WHICH ALL THE TCP/ 
IP INTERFACES ARE OPERATING " 
: : = { smgTotal 4 } 

smgTotalRouterNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE NUMBER OF ROUTERS WHICH ARE WITHIN THE 
MANAGEMENT RANGE OF THE SUB-MANAGER " 
: : = { smgTotal 5 } 

smgTotalSnmpSuDpprtNodeNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE NUMBER OF NODES WHICH ARE LOADED WITH 
SNMP WITHIN THE MANAGEMENT RANGE OF THE SUB- 
MANAGER " 

: : = { smgTotal 6 } 

- SUB-MANAGER IP NODE GROUP 
(the Submanager IpNode group) 

smglpNodeTable OBJECT-TYPE 

SYNTAX SEQUENCE OF SmglpNodeEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

" SHOWS A LIST OF INFORMATION RELATING TO THE IP NODE 
WITHIN THE MANAGEMENT RANGE OF THE SUB-MANAGER " 
: : = { smglpNode 1 } 

SmglpNodeEntry OBJECT-TYPE 

SYNTAX SmglpNodeEntry 

ACCESS not-accessible 

STATUS mandatory 

INDEX ( smglpNodelndex } 
: : = { smglpNodeTable 1 } 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 6 of 39 5,651,006 



FIG.6 

SmglpNodeEntry : : = SEQUENCE f 

y smglpNodelndex INTEGER 

^ smglpNodeContext Display String 

smglpNodelndex OBJECT-TYPE 
SYNTAX INTEGER (..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"A UNIQUE VALUE FOR EACH SYSTEM 
THIS VALUE MUST BE CONSTANT UNTIL THE SUB- 
MANAGER HAS BEEN RE-INITIALIZED " 
: : = { SmglpNodeEntry 1 } 

smglpNodeContext OBJECT-TYPE 
SYNTAX DisplayString 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

" AN ENTRY WHICH INCLUDES INFORMATION FOR EACH IP 

NODE WITHIN THE MANAGEMENT RANGE 
THE FOLLOWING INFORMATION ARE INCLUDED : 

( 1 ) IP ADDRESS : SHOWS THE HP ADDRESS USED FOR 
v ' THE INTEGRATION MANAGER TO 

COMMUNICATE WITH THE HOST 

A SOFTWARE LOOP-BACK ADDRESS IS 

NOT USED 

( 2 ) HOST NAME : SHOWS THE HOST NAME OF THE IP _ 
v ' NODE WITHIN THE MANAGEMENT RANGE 

A NAME DEFINED IN THE /etc /hosts 
WITHIN THE HOST OF WH CH SUB- 
MANAGER IS OPERATING IS USED 
IF THE NAME IS NOT DEFINED, THIS 
ITEM BECOMES A BLANK t ^ 

( 3 ) STATUS : SHOWS THE STATUS OF THE IP NODE 
V ' WITHIN THE MANAGEMENT RANGE im 

THERE ARE THE FOLLOWING STATUSES : 



NORMAL ( Normal ) 
MARGINAL (Marginal ) 

CRITICAL (j Critical f t _ 

(4, PING RESPONSE ^TIME: SHOVjfe A RESPONSE TjM^OF 



f 5 ) SNMP SUPPORT 

1 INFORMATION: SHOWS WHETHER THE IP NODE OF 

THE MANAGEMENT RANGE SUPPORTS 
THE SNMP OR NOT 
THERE ARE THE FOLLOWING VALUES : 



(a) SUPPORT (snmp) 
(bj NOT SUPPORT! nonsnmpj 
TION 



(6) ROUTER INFORMATION : SHOWS WHETHER TrfE IP NODE e 
x ' WITHIN THE MANAGEMENT RANGE 

IS A ROUTER OR NOT 
THERE ARE THE FOLLOWING 
VALUES : 
(a) ROUTER (router) 
(b \ NOT A ROUTER ( host ) 
AN EXAMPLE OF OUTPUT IS SHOWN BELOW 
203. 200. 100. 150. hostOOl Normal 10 nonsnmp router 

: : = { SmglpNodeEntry 2 } 
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FIG.7 

- SUB-MANAGER REAL-TIME COLLECTION MIB GROUP 
(The Submanager Summary Tcp group) 

smgSumTcpTable OBJECT-TYPE 
SYNTAX SEQUENCE OF SmgSumTcpEntry 
ACCESS not-accessible 
STATUS mandatory 
DESCRIPTION 

" SHOWS THE LIST OF TCP COLLECTION WITHIN THE 
MANAGEMENT RANGE OF THE SUB-MANAGER 0 
: : = { smgSumTcp 1 } 

SmgSumTcpEntry OBJECT-TYPE 
SYNTAX SmgSumTcpEntry 
ACCESS not-accessible 
STATUS mandatory 

INDEX { smgSumTcpServerlpAddress, smgSumTcpServerPortNumber, 
smgSumTcpClientlpAddress, smgSumTcpClientPortNumber } 
: : = { smgSumTcpTable 1 } 

SmgSumTcpEntry : : = SEQUENCE { 

smgSumTcpServerlpAddress 

IpAddress, 
smgSumTcpServerPortNumber 

fNTEGER, 
smgSumTcpClientlpAddress 

IpAddress, 
smgSumTcpClientPortNumber 

INTEGER, 
smgSumTcpContext 

Display String 

smgSumTcpServerlpAddress OBJECT-TYPE 
SYNTAX IpAddress 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

"SHOWS THE IP ADDRESS AT WHICH THE TCP CONNECTION IS 
OPENED " 

: : = { SmgSumTcpEntry 1 } 

smgSumTcpServerPortNumber OBJECT-TYPE 
SYNTAX INTEGER (0..65535) 
ACCESS read-only 
STATUS mandatory 
DESCRIPTION 

-SHOWS THE PORT NUMBER WHICH IS USED BY THE NODE 
DEFINED BY smgSumTcpServerlpAddress" 
: : = { SmgSumTcpEntry 2 } 
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FIG.8 

smflSumTcpClientlpAddress OBJECT-TYPE 
IpAddress 
read-onfy 



rep 
(Salary 



"SHQwi^HE IP ADDRESS (THE OTHER PARTY DEFINED BY _ 
SPM WH,CH ™ E CONNECTION IS 

= { smgSumTcpEntry 3} 



{smgSumTcpEntry 3} 
smfl&imlPP^ OBJECT-TYPE 

read-only 
tdry 

: = { smgSum 




mandati 
ION 

HOWS THE PORT NUMBER WHICH IS USED BY THE IP NODE 
JEFINK) BY smgSumTcpClientlpAddress " 
rigSumTcptntry 4} 



smj 




ntexl OBJECT-TYPE 
_ isplay .String 
read-only 
ndatory 




( 2 ) PORT NUMBER ( PART 2 ) 



mr. 

THE TCP 



1): 



)NNECTION 



SUB- MANAGER ^ 

(b) dosedd): ^A^^^K FROM 

DISCONNECTION REQUEST 

( c ) listen ( 2 ) : IS WAITING FOR A JX)N 
\ i "-CTION OPEN I 



OPTION 



)PEN FROM OTHER 



(d) synSent ( 3 ) : I 



(e) synReceived ( 4 



(f) established ( 5 ) : HA 

)A 




M 



A CON- 
EST AND 

RKHJEST 
IDE AND IS 

A " 
TION 
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FIG.9 

( g ) fin Wait 1(6): IS WAITING FOR A DISCON- 

NECTION REQUEST FROM 
THE OTHER TCP OR HAS 
ISSUED A DISCONNECTION 
REQUEST AND IS WAITING 
FOR ACK OF THIS REQUEST 

(h) fin Wait 2(7): IS WAITING FOR A DISCON- 

NECTION REQUEST FROM 
THE OTHER TCP 
(I) close Wait (8): IS WAITING FOR A DISCON- 
NECTION REQUEST FROM 
THE USER 

( j ) last Ack ( 9 ) : IS WAITING FOR ACK FROM 
THE OTHER TCP TO A DIS- 
CONNECTION REQUEST 
(k) closing (10): IS WAITING FOR ACK FROM 
THE OTHER TCP TO A DIS- 
CONNECTION REQUEST 
( I ) timeWait ( 11 ) : IS WAITING UNTIL THE ACK 
ISSUED FROM THIS SIDE 
HAS REACHED THE OTHER 
PARTY AND HAS BEEN 
PROCESSED 

(4) IP ADDRESS ( PART 2 ) : SHOWS THE IP ADDRESS OF THE IP 

NODE WHICH OPENS THE TCP CON- 
NECTION (THE OTHER PARTY OF 
THE NODE DEFINED IN THE IP 
ADDRESS (1 ) ) 

(5) PORT NUMBER (PART 2): SHOWS THE PORT NUMBER WHICH 

IS USED BY THE IP NODE DEFINED 
IN (5) IN THIS TCP CONNECTION 

( 6 ) STATUS ( PART 2 ) : SHOWS THE STATUS OF THE TCP CON- 

NECTION WHICH IS OPENED BY THE IP 

NODE DEFINED IN (5) 

THE DEFINED VALUE IS DEFINED IN ( 4 ) 

( 7 ) SERVICE NAME : SHOWS THE SERVICE NAME WHICH USES 

THIS TCP CONNECTION 
THE SERVICE NAME USED IS THE NAME 
DEFINED IN THE / etc / services OF THE HOST 
OF WHICH SUB-MANAGER IS OPERATING 

AN EXAMPLE OF OUTPUT IS SHOWN BELOW 

203. 200. 100. 150 5648 established 200. 158. 123. 203 6300 unknown 

ftp" 

: : = { smgSumTcpEntry 5 } 
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FIG.10 

- SUB-MANAGER EXTENSION TRAPS ( the submanager specific traps ) 

smgCreateSystemTrap TRAP-TYPE 
ENTERPRISE submanager 
VARIABLES { smglpNodelndex } 
DESCRIPTION 

" THE TRAPS ARE USED FOR POSTING THAT A SYSTEM 
HAS BEEN ADDED 

smglpNodelndex IS THE INDEX HELD BY THE ADDED 
SYSTEM " 

::= 1 

smgDeleteSystemTrap TRAP-TYPE 
ENTERPRISE submanager 
VARIABLES { smglpNodelndex } 
DESCRIPTION 

" THE TRAPS ARE USED FOR POSTING THAT A SYSTEM 
HAS BEEN DELETED 

smglpNodelndex IS THE INDEX HELD BY THE ADDED 
SYSTEM ■ 

: := 2 

smglntermediaryTrap TRAP-TYPE 

ENTERPRISE submanager 
VARIABLES { smgTrapList } 
DESCRIPTION 
" RELAY TRAP 

VALUES OF THE ENTERPRISE CODE (enterprise ) OF THE 
AGENT WHICH HAS ISSUED A TRAP TO BE RELAYED, 
THE NETWORK ADDRESS ( agent-addr ), THE STANDARD 
TRAP NUMBER (generic-trap) AND THE EXTENSION TRAP 
NUMBER ( specificTrap ) ARE SET TO THE variable-bindings 
FIELD AS THE VALUES OF smgEnterprise, smgAgentAddr, 
smgGenericTrap, AND smgSpecificTrap RESPECTIVELY 
THE VALUES OF THE variable-bindings FIELD OF THE 
RELAY TRAP CONSTITUTE A PART OF THE variable- 
bindings FIELD OF THE RELAY TRAP AND ARE RELAYED 
TO THE MANAGER 

::= 3 

SmgTrap : : = 

SEQUENCE { 



} 



smglpNodelndex, 
smgEnterprise, 
smgAgentAddr, 
smgGenericTrap, 
smgSpecificTrap, 
vanableBindings 



SmgTrapList : : = 

SEQUENCE OF 
SmgTrap 

END 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 11 of 39 



5,651 



0)1 



2 

< 

UJ 

tr 



gp 

qO 

Eds 

clOS 



z 

UjO 

f& 

_J -J 

ecus 



O 



Q 
UJ 
I— 



LUqLU 
<UJ<H 

Ills 



Q) 
C 

o 

o 
Z 

Q, 
D> 

E 

CO 



CO 
CO 
CP 

< 

* % 

o a> 
O CO 
a. a. 

E E 

CO CO 
O) O) 

E E 

CO CO 



0) 

E 

z 

tr 

o 

a. 
i_ 

CD 

cd 
CO 
Q. 
O 



cp 



C 

CP 



c 

CP 



O O 

O. Q. 
o o 



E E E 

CO CO CO 

0 0)0) 

E E E 

CO CO CO 



o 

1X1 

O 
UJ 

-J 

o 
o 

LU 
GQ 



Z 

o 



cc 
o 



CO 

cr 

UJ 

x 
h- 
o 



LU 

< 
Z 

& 

UJ 

CD 
O 



CD 



cc 

UJ 
CQ 



CO 

o 



OUJ 



T3 

c5 



u5tj 

^ O 

it 



CM 



t3 

CD 
IT 

o 

CO 



CD 

ex 

t 



in 



CO 
3 
CO 

CD 
Q. 

O 



CD 



CO 
<D 
O 

*£ 
CD 
CO 

U Ul 

5s! 



CO 
CO 
CP 



O) 

c 

w 
CO 



CL 



CO 
CO 

^ CP 

P -o o 

% < Q- 

S E E 

o o> CP 

J DC DC 

c c c 

c c c 

o o o 

O O O O 

0 D. Q. Q. CL 

o B S S H 



< 

cp co 

CO O 

! i 

O 



CO 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 12 of 39 



5,651 



CM 

T— 

o 



o 
o 

CM 



X 
0) 

o 
O 

z 
a 

E 

to 

LL 
O 

(0 
I- 

z 
lii 

z 

o 
o 



8 

CM 



5oz 

cc5=h 



o 
in 

CM 



z 

o 

SctP 

COCO? 



o 

CM 



UJ 
(0 

z 

o 
a. 

(0 
LU 

cc 

ouj 
Z5 

Q.h 



O 
CO 
CM 



to 

1 



o 

CM 
CM 



o< 

IZ 



o 

CM 



CO 
CO 
HI 

cc 



CO 

O 

LL 



o 
o 

CO 



C 

o 
O 
a 

E 

CO 
O) 

E 

CO 



CO 

z 

UJ 
I- 

z 
o 
o 



o 

CO 



UJ 

o 

UJ< 

coz 



o 

CO 
CO 



CO w 



o 
in 

CO 



UJi_ 
DC 2 < 
QL Z w 



O 
CO 



wi- 
pe cc 

s< 



o 

CO 
CO 



0> 

COw 



o 

CM 
CO 



DC ^ 
LU. 

iEii 

CLZ w 



CO 



co^T 
co^ 

£oc 
9=§i 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 13 of 39 



5,651,006 



o 
o 



V 



g 

LL 



co 



u. 
O 

MS 

^ _i m 

< ID 



ZWQ.C0 



d)CD 
31 

EP 

Pi 

Ou_o 
OOP 



2§ 



Eds 

0.O5 



E 
Z 
* 

O 

Z 

a> 

O) 
€0 

c 

CO 

1 

E 

CO 



X 
CD 

■a 
c 

cd 

"D 

O 

Z 

uj p 
co E 

CO * 

go 

-1 

o z 
ujE 



2 

E 
=> 
z 

a> 
Z 
I 

C 

O 
ca 

i 

E 

CO 



CD 
X5 

E 
z 

<D 
"D 
O 

z 

CO 

c 

E> 

(0 

1 

i 

E 

CO 



CD 

E 

z 

<D 
O 

z 

(0 



O 

z 

CO 

I 

E 

CO 



0) 
X> 

E 

z 

CD 
"D 
O 

z 

O 

eg 

CO 

o 
E 

CO 



0) 

E 

3 

z 

"8 
z 

o 

CL 

a 

3 

CO 

Q. 

E 
c 
CO 

CO 



O) 

E 

CO 



CO 



CO 



CM 



CO 



en 
o 
u. 
z 



12 

O 

a: 



in 



z 
o 

2 

CC 
O 



CC 

2 

CL 
D 
CO 



z 

CO 



CO 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 14 of 39 



5,651,006 



o 

CM 



I 



in 

T— 

CD 

LL 



03 J3 (0 .Q 

o oo o o o o o 

o t-cvj cm co m* "t m 

^ ^ t 



o 

CO 



HI 

u. 
CD 

z 

E 

CO 
UJ 

z 
o 
cr 

> 
z 

UJ 



§>$OZGZ 

„ DhQh 
DCDC<C0<W 

oo« o„ o 

U-UL^CL^QL 



lit 

I- 
z 



UJ 



-Q 
3 
Q. 

II 

Z wop 

II 

— Uiod 

vis 

zfc ■ 

D iz 

QQUJCr 
OC0H- 



co 



oo 

CM CM 

do 



88 

OCMCM 

" 

" UJ UJ 

^zz 



is S<<o 



zcoco 

HJUJLJJ< 
0(£(E> 
ZD Off. 

CC<<£ 

zzz>- 

UJUJUJ< 
UJUJUjUJ 

zzz< 

«<ct 



CM 
O) 

T- 

II 

z 

o 

I— 

< 
z 

I- 

CO 
UJ 
Q 

Q. 
< 



co 



= UJ 



UJ 



co2< - CO 

< CO 
KCC>. UJ 3 

COUJD o^Z^ 

CO o ^ Q. Ill 

*<8 ■ 




UJfr< 1 UJUJUJrt 

oecwiiij 

<occoI | - hK S 

IS^-ooouj 

,. U_(_UJLJ_li_ll.U 

O^ZtWUJUJ. 

OQqjZqqqI^ 

itozffffc 

oujsy uj 
<l-= h- 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul 22, 1997 



Sheet 15 of 39 



5,651,006 



C&D OT3 (Dh- QIC.. 



CO 

o 

LL 



UJ 
-J 
GO 

2 

Z 

o 

$ 

z 
»- 

CO 
UJ 
Q 

Q. 
< 

cc 



° (013 0*0 

to oooo 

I 1111 

1 wwwm 



t 
z 

D 

cc 



o 
o 

X 



o 

co' 
z! 

UJ 
h- 
Z 
O 

o 



m 



o 

CM 

in 



ooooooo ooo o 

CMCMCMCMCNJCMCM CMCMCM CM 

iniomiamtom muxo io 

> M M ) ) ) > > ) 



<D-4- O) £ 
OOO O 

) 1 _j 1 



111S 



OOO 



io in 
J Tt- 



mi 



Pas®! 

U a' a^ri r m^it 



UJ 



UjUl 

II 

WW 

zz< 

UjUl 

2 



MjUJ 



UjUj 
UldW 



UI 



Lil 
21 



LU 
CO 



1 DC 

IOq. 



o 
o 



& 

(Dui 
<o 

2Z 

^< 

5CC 



1- 






• z 






D 




CM 


_l 


> 


> 


O 


cc 


cc 


CC 




1- 


K- 


z 


z 


Z 


UI 


UJ 


o 






o 








CD 
JO 

_ I 

I, I i = 

«Z7C 

£ 32 -g q. 

IP 

ffl o o c 
5 Z DC CO 

2 5 5 5 
£.2,2,2 

O) 0> O) O) 

E E E E 
co co co co 



i- CM CO W (O 

****** 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 16 of 39 



5,651,006 



FIG.17 

MANAGEMENT RANGE MONITORING SYSTEM ( MAIN ) 



( START ) 



600 



INITIALIZING THE 

MANAGEMENT 

RANGE 



610 



LOOP UNTIL AN 
END REQUEST 
HAS BEEN 
RECEIVED 



( END ) 



MONITORING OF 
THE MANAGEMENT 
RANGE 



TOTAL 

PROCESSING 



UPDATING THE 

MANAGEMENT 

RANGE 



•620 



630 



-640 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent Jul. 22, 1997 Sheet 17 of 39 



5,651,006 



FIG.18 



c 



START 



C 



INITIALIZATION OF THE MANAGEMENT RANGE 



REFER TO 
THE 

ENVIRONMENT 
SETTING FILE 



SET THE 
MANAGEMENT 
RANGE TABLE 



650 



•651 



OBTAIN 
atNetAddress 
FROM THE 
SELF-AGENT 
FUNCTION OF 
THE SUB- 
MANAGER 
ITSELF 



653 



OOP BY THE 
UMBER OF 
tNetAddress 
URING THE 
ERIOD 
HILE A 
ACANT 

:ntry exists: 

N THE 
ANAGEMENT 
GE TABLE 



652 



^ 65 4 YES 



IS THE VALUE 
OF 

atNetAddress 
INCLUDEO IN 
THE 

MANAGEMENT ' 
ADDRESS 
RANGE ? 



655 



ISSUE ping 
TO THE IP 
NODE OF THE 
VALUE OF 
atNetAddress 



656 



YES 



IS THERE A 
RESPONSE 
TO THE 
PING ? 



END 



657 



SET THE VALUE 
OF atNetAddress 
TO THE IP 
ADDRESS IN 
THE VACANT 
ENTRY OF THE 
MANAGEMENT 
RANGE TABLE 



658 



ISSUE (ADD) 
THE SUB- 
MANAGER 
EXTENSION 
TRAP TO THE 
INTEGRATION 
MANAGER 



659 



SET THE 
FOLLOWING 
VALUES BY 
REFERRING TO 
THE 

MANAGEMENT 

ADDRESS 

RANGE OF THE 

ENVIRONMENT 

SETTING RLE : 

COMMUNITY 

NAME, 

POLLING 

INTERVAL, 

TIME-OUT TIME 



660 



SET THE 
CORRESPOND- 
ING HOST NAME 
BY REFERRING 
TO THE /etc/ 
hosts RLE 



661 



SET 'Normal" 
TO THE STATUS 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 18 of 39 



5,651,006 



MONITORING THE MANAGEMENT RANGE 

_ .672 

( START ) 



LOOP BY THE 
ENTRY 
NUMBER OF 
THE MANAGE- 
MENT RANGE 
TABLE 



670 



REFER TO THE] 
MANAGEMENT 
RANGE TABLE 



671 



^1 



ping 
PROCESSING 



673 



IS THERE IP 
ADDRESS 
AND IS THE 
STATUS 
OTHER THAN 1 
"Critical" ? 



FIG.19 



674 



ISSUE AN 
SNMP 

REQUEST TO 
THE CORRE- 
SPONDING IP 
ADDRESS IN 
ORDER TO 
OBTAIN THE 
FOLLOWING 
MIB-II 
VALUES : 
sysObjectID 
ifNumber 
ifType 

ifOperStatus 
AND 

ipForwarding 



675 



YES 



IS THERE A 
RESPONSE 
TO THE 
SNMP 

REQUEST ? 



676 



SET "snmp" 
TO THE SNMP 
SUPPORT 
INFORMATION 



677 



ROUTER 
DECISION 



NO 



^680 YES ^ 681 



IS THERE A 
CHANGE IN 
THE ENTRY ?' 



STORE THE 

CHANGED 

INFORMATION 

IN THE 

COLLECTION 

DATA BASE 

MANAGEMENT 



678 



SET "nonsnmp" 
TO THE SNMP 
SUPPORT 
INFORMATION 



.679 



SET "host" TO 
THE ROUTER 
INFORMATION 



C D ) 



08/26/2003, EAST version: 1.04.0000 



U.S. Patent 



Jul 22, 1997 



Sheet 19 of 39 



5,651,006 



FIG.20 



( START ) 



ROUTER DECISION 



,690 



SET "host" TO 
THE ROUTER 
SUPPORT 
INFORMATION 



691 



=1 



IS THE 
VALUE OF 
ipForwarding 
"1" 

(gateway) ?J 



692 



YES 



IS THE 
VALUE OF 
ifNumber AT 
LEAST 
"2" t 



693 



YES 



ARE THERE A / 
PLURALITY OF / 
INTERFACES / 
OF WHICH / 
VALUE OF / 
ifType IS ( 
OTHER \ 
THAN "24* \ 
(*) AND ARE \ 
THE VALUES \ 
OF ifOperSlatus \ 
ALL ° 1 " ( UP ) ?\ N0 



697 



SET ' Normal ' 
TO THE STATUS 



698 



YES 



IS THE 
VALUE OF 
ifNumber AT 
LEAST 

ti 2 » 7 



699 



YES 



ARE THERE A / 
PLURALITY OF / 
INTERFACES / 
OF WHICH / 
VALUE OF / 
ifType IS / 
OTHER \ 
THAN "24" \ 
(*) AND ARE \ 
THE VALUES \ 
OF ifOperStatus \ 
ALL"1° (UP)?\ N0 



702 




694 



SET "router" 
TO THE 
ROUTER 
INFORMATION 



695 



SET "Normal' 
TO THE 
STATUS 



696 



SET "Marginal' 
TO THE 
STATUS 



700 





C ) 



(*) "24" OF ifType MEANS softwareLoopback 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 20 of 39 



5,651,006 



c 



START 



3 



710 



CLEAR THE 
ping 

RESPONSE 
TIME 



FIG.21 

ping PROCESSING 
713 



711 



ISSUE ping 



712 



YES 



IS THERE A/ 
RESPONSE 
TO THE 
ping ? 



END ) 



SET THE ping 

RESPONSE 

TIME 



714 



CLEAR THE 
OLDEST TIME 
WHEN THE 
ping 

RESPONSE 
FINISHED 



715 



YES 



IS THE SNMP 
SUPPORT 
INFORMATION 
"nonsnmp" ? 




716 



SET "Normal' 
TO THE 
STATUS 



,717 



,718 



SET 

" Marginal • TO 
THE STATUS 



SET •Critical" 
TO THE STATUS 



719 



YES 



IS THERE THE 
OLDEST TIME] 
WHEN THE 
ping 

RESPONSE 
FINISHED ? 



720 



YES 



HAS A PREDE- / 
TERMINED TIME / 
( FOR EXAMPLE,/ 
ONE WEEK) ( 
PASSED SINCE \ 
THE OLDEST \ 
TIME ? \ 



I NO 



723 



SET THE 
CURRENT 
TIME TO THE 
OLDEST TIME 
WHEN THE 
ping 

RESPONSE 
FINISHED 



721 



DELETE THE 
CONTENTS 
( IP ADDRESS ) 
OF THE 
CORRESPOND- 
ING ENTRY 



722 



ISSUE 

(DELETE) THE 

SUB-MANAGER 

EXTENSION 

TRAP TO 

(FROM) THE 

INTEGRATION 

MANAGER 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 21 of 39 5,651,006 



c 



START 



c 



REFER TO THE MANAGE- 
MENT RANGE TABLE 



FIG.22 

TOTAL PROCESSING 



730 



CLEAR THE COUNTER 
smgTotalManagedNodeNumber— 0 
smgTotalCnlicalNodeNumber— 0 
smgTotalMarginalNodeNumber— 0 
smgTotalNormalNodeNumber— 0 
smgTotalRouterNodeNumber— 0 
smgTotalSnmpSupportNodeNumber— 0 



731 



732 



YES 



LOOP BY 
THE ENTRY 
NUMBER 
OF THE 
MANAGE- 
MENT 
RANGE 
TABLE 



IS 
THERE 
AN IP 
AD- 
DRESS! 



733 



status; 



734 



COUNT UP (+1) 
smgTotalManagedNodeNumber 



=" Critical" 



735 



736 



COUNT UP (+1) 
smgTotalCriticalNodeNumber 



Y Marginal " 



737 



COUNT UP (+1) 
smgTotalMarginalNodeNumber 



W Normal" 



738 



COUNT UP (+1) 
smgTotalNormalNodeNumber 



ROUTER / 
SUPPORT ( 
INFORMATIONX 


COUNT UP (+ 1 ) 
smgTotalRouterNodeNumber 


^741 = . snmp - ^742 


SNMP / 
SUPPORT ( 
INFORMATIONX 


COUNT UP ( + 1) 
smgTotalSnmpSupportNodeNumber 



^743 y ES 

IS THERE A / 
CHNGETO / 
THE TOTAL-/ 
ED RESULT \ 
(COUNTER \ 
VALUE ) ? \ 



744 



STORE THE 
CHANGE IN 
THE COLLECTION 
DATA BASE 



END 



3 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 22 of 39 



5,651,006 



( START ) 



FIG.23 

UPDATING OF MANAGEMENT RANGE 



YES 



HAS A 
PREDE 
TERMINED 
TIME 
(FOR 
■EXAMPLE, 
THREE 
HOURS J 
PASSED 
SINCE 
THE 
LAST 
UPDAT- 
ING ? 



( END ) 



751 



LOOP WHILE 
THERE IS A 
VACANT 
ENTRY 
IN THE 
MANAGE- 
MENT 
RANGE 
TABLE AND 
THE STATUS 
IS OTHER 
THAN 
" Critical " 
AND THE 
SNMP 
SUPPORT 
INFORMA- 
TION IS THE 
IP ADDRESS 
OF ' snmp ' 



'NO 



750 



ISSUE AN SNMP 
REQUEST IN 
ORDER TO 
OBTAIN THE 
VALUE OF 
atNetAddress 
FROM THE IP 
ADDRESS OF THE 
CORRESPONDING 
ENTRY 




^753 YES 


LOOP 

DURING THE 


IS THERE A / 
RESPONSE / 
TO THE / 
SNMP / 
REQUEST ?/ 

\nc 


PfcRIOD 
WHILE 
THERE IS A 
VACANT 
ENTRY 
IN THE 
MANAGE- 
MENT 
RANGE 
TABLE AND 
BY THE 
NUMBER OF 
THE VALUE 
OF 

atNetAddress 






SET 

"Critical" TO 
THE STATUS 



754 



755 



UPDATE 
PROCESS- 
ING 



-756 



C 



START 



3 



FIG.24 

UPDATE PROCESSING 



760 



YES 



IS THE IP ADDRESS NOT THE 
ONE WHICH EXISTS IN THE 
MANAGEMENT RANGE TABLE 
AND IS THE IP ADDRESS 
INCLUDED IN THE 
MANAGEMENT ADDRESS 
RANGE ? 



NO 



( ) 



761 



ADD THE VALUE OF 
atNetAddress TO THE VACANT 
ENTRY IN THE MANAGEMENT 
RANGE TABLE 



ISSUE (ADD) THE SUB- 
MANAGER EXTENSION 
TRAP TO THE INTEGRATION 
MANAGER 

^ 



762 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 23 of 39 5,651,006 



FIG.25 



( START ) 



ALLOCATION METHOD 
(COMMUNICATION CONTROL FUNCTION) 



773 



770 



SNMP 
REQUES 



LOOP UNTIL AN 
END REQUEST 
HAS BEEN 
RECEIVED 



HAS 
DATA 
BEEN 

RECEIV-, 
ED ? 



SNMP 
RE- 
SPONSE 



YES 



IS THE 
OBJECT 
IDENTI- 
FIER A 
SUB- 
MANAGER 
EXTENSION 1 
MIB ? 



POST TO 
THE SUB- 
MANAGER 
AGENT 
FUNCTION 



.772 



774 



RESPOND 
TO THE 
INTEGRATION 
MANAGER 



:SNMP 

TRAP 



POST TO 
THE TRAP 
MANAGEMENT 
FUNCTION 



^OTHERS 



POST TO 
THE SELF- 
AGENT 
FUNCTION 



775 



776 



( ) 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



JuL 22, 1997 



Sheet 24 of 39 



5,651,006 



^ FIG.26 

I START ) ALLOCATION METHOD (SUB-MANAGER AGENT FUNCTION) 



LOOP 
UNTIL 
AN END 
RE- 
QUEST 
HAS 
BEEN 
RECEIV- 
ES 



780 



= SNMP 
REQUEST 



784 



HAS 
DATA 
BEEN 
RECEIV- 
ED ? 



782 
781 



YES 



HAS THE 
COMMUNITY/ 
NAME 
MATCHED 
AND IS 
THIS AN 
OBTAIN 
REQUEST] 



YES 



IS THE 
SNMP 
REQUEST 
A get -next 
OPERA- 
TION'? 



CALCULATE 
THE NEXT 
OBJECT 
IDENTIFIER 



783 



YES 



IS THE 
OBJECT 
IDENTIFIER 
A 

PERIODICAL 
COLLECTION 
MIB 7 




786 



POST TO THE 
COLLECTION 
DATA BASE 
MANAGEMENT 
FUNCTION 



785 



787 



\NO 



= RESULT 



RES 


PONSE 




BUILD UP THE 




SNMP 




RESPONSE 








RETURN THE 




SNMP 




RESPONSE 




TO THE 




COMMUNICA- 




TION 




CONTROL 




FUNCTION 



RETURN AN 
ERROR 
RESPONSE 
TO THE 
COMMUNICA- 
TION 

CONTROL 
FUNCTION 



POST TO THE 
CONCENTRA- 
TION 

FUNCTION 



788 



789 



-790 



= OTHERS 



C ) 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 25 of 39 5,651,006 



CM 

d 

LL 




DOZ 



d.2s 
3e8:p 
z =>i 

CO CO ^ 



UJ 

CO 

z 
o 

CL 
O)C0 



111 



CUJ£ 

ate- 



(0 

i 



o< 

12 



CO 
CO 
UJ 

<r 
o 
o 

: <: 




08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 Sheet 26 of 39 5,651,006 



( START ) 



FIG.28 

COLLECTION DATA BASE MANAGEMENT FUNCTION 



820 



= OBTAIN 
REQUEST 



YES 



823 



LOOP 
UNTIL 
AN END 
RE- 
QUEST 
HAS 
BEEN 
RECEIV- 
ED 



HAS 
DATA 
BEEN 
RECEIV-/ 
ED ? 



•821 



824 



get -next 
OPERA- 
TION ? 




822 
YES 



OBTAIN THE 
NEXT INDEX 



825 



DOES THE 
ASSIGNED 
INDEX 
EXIST ? 



826 



BUILD UP THE 
COLLECTION 
MIB VALUE TO 
BE RESPONDED 



RESPOND THE 
RESULT TO THE 
SUB-MANAGER 
AGENT FUNCTION 



(NO 



l= STORE 
1 REQUEST 


827^ 


UPDATE THE 
ASSIGNED 
CONTENTS OUT 
OF THE INFOR- 
MATION WHICH 
STRUCTURES 
THE COLLECTION 
MIB VALUE HELD 
IN THE MEMORY 




= REFER- 
> ENCE 
\ REQUEST 


UPDATE THE 
CONTENTS OF 
THE COLLECTION 
MIB DATA BASE 


PROVIDE THE 
ASSIGNED 
CONTENTS OUT 
OF THE INFOR- 
MATION WHICH 
STRUCTURES 
THE COLLECTION 
MIB VALUE 





RETURN AN 
ERROR 

RESPONSE TO 
THE SUB- 
MANAGER AGENT 
FUNCTION 



-828 



-829 



830 



C ) 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 27 of 39 5,651,006 



FIG.29 



AN EXAMPLE OF THE GRAPH DISPLAY IN THE INTEGRATION MANAGER 
OF THE TOTALED VALUE WHICH IS THE COLLECTION MIB 



TARGETED SUB-MANAGER IP ADDRESS : 200. 10. 20.1 
POLLING INTERVAL: TEN (MINUTES) 

a smgTotalManagedNodeNumber d :smgTotalCriticalNodeNumber 

b — — smgTotalMarginalNodeNumber e :smgTotalNormalNodeNumber 

c smgTotalRouterNodeNumber f ismgTotalSnmpSupporlNodeNuinber 



100 



MIB 
VALUE 

50 



TIME 



FIG 30 TCP CONNECTION TARGETED BY THE 
CONCENTRATION FUNCTION 



MANAGEMENT 
20a RANGE 



SUB-MANAGER 




: TCP CONNECTION 

1000, - 1010 : TARGETED TCP CONNECTION 
1020 : TCP CONNECTION NOT TARGETED 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 28 of 39 



5,651 




HI 



13 

Sssfr 



GO 

5 

UJ 

I 

K- 

ll tr 
O uj 

03 t 



CO 
LL 



5 

(0 
c 
c 
o 
O 

Q. 
U 



HI 
3 
-J 
< 
> 

Q 
Z 
< 

o 
z 

UJ 
X 

I- 
o 

i 

DC 

o 

uu 



o 
< 



CO 

UJ 




UJ CO 

{— CO 

03 Q 

cr § 



<CLfc 



< 



to 

35 

c 
c 
o 

O 

Q. 
O 



C 
ill 

c 
c 
o 
O 

Q. 
O 
♦<-* 

0) 

fi 

c 
c 

o 
O 

Q. 



O 



i5 

o 
z 



CD 



z 
o 

O 
UJ 
—J 
_J 

O 
o 

UJ 

2 



5 

cc 

UJ 
X 

u. 

CM O 
3 

O I 

— o 

"■I 

E 

3 
CO 

o> 
E 

(0 

u. 
O 

tr 

O 
u. 

Q 
Z 
< 



2 

o 
z 








CO 



08/26/2003, EAST Version: 1.04.0000 



,S. Patent jui. 22, 1997 sheet 29 of 39 5,651,006 



CO 
CO 

O 

Li. 




zoo. 



If 

Ceo 
O E 



ZQQ. 
OUJ"" 

^UJDCQQ- 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 30 of 39 5,651,006 

FIG.34 

SEQUENCE OF THE INDEX OF THE REAL-TIME COLLECTION MIB 

310 320 340 350 



SEQUENCE 


) ) CONTENTS OF THE INDEX ) ) 


OF THE 
INDEX 


IP ADDRESS 
( PART 1 ) 


1 PORT 
NUMBER 
(PART 1) 


IP ADDRESS 
(PART 2) 


PORT 1 
NUMBER 
(PART 2) 


INDEX # 1 


IP ADDRESS 
OF THE 
ENTRY # 1 




Ul 


IP ADDRESS 
OF THE 
ENTRY # 2 


SMJ 


Ml 












r 






IP ADDRESS 
OF THE 
ENTRY # 1 






IP ADDRESS 
OF THE 
ENTRY # 3 






















IP ADDRESS 
OF THE 
ENTRY # 1 






IP ADDRESS 
OF THE 
ENTRY # X 














< 


r 






IP ADDRESS 
OF THE 
ENTRY # 1 






IP ADDRESS OF 
OUTSIDE THE 
MANAGEMENT 
RANGE 






















IP ADDRESS 
OF THE 
ENTRY # 2 






IP ADDRESS 
OF THE 
ENTRY # 3 








f 














IP ADDRESS 
OF THE 
ENTRY # X 


LARGE 


IP ADDRESS OF 
OUTSIDE THE 
MANAGEMENT 
RANGE 


LARGE 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 Sheet 31 of 39 5,651,006 



FIG.35 



( START ) 



METHOD OF CONCENTRATING THE 
MANAGEMENT RANGE (MAIN) 



-1203 



1202 



1200 



= OBTAIN 
REQUEST 



LOOP 

UNTIL 

AN END 

REQUEST 

HAS 

BEEN 

RECEIVED 



HAS 
DATA 
BEEN 

RECEIVED! 

? 



YES 



OPERATION , 

7 



CARRY OUT get 
PROCESSING 



1204 



CARRY OUT 
get • next 
PROCESSING 



YES 



1206 



NO ERROR 

1 



1205 



( END ) 



~7~ 

1201 



OBTAIN THE 
CORRESPONDING 
SERVICE NAME 
BY REFERRING 
TO THE /etc/ 
services FILE 



-1207 



BUILD UP THE 
REAL-TIME 
COLLECTION MIB 
VALUE TO BE 
RESPONDED 



-1208 



RESPOND THE 
RESULT TO THE 
SUB-MANAGER 
AGENT 
FUNCTION 



iN O ^1209 

~ RETURN AN 
ERROR 

RESPONSE TO 
THE SUB- 
MANAGER 
AGENT FUNCTION 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 32 of 39 5,651,006 



( START ) 



FIG.36 

get PROCESSING 



BREAK DOWN THE 
INDEX AND OBTAIN 
THE FOLLOWING 
INFORMATION : 
IP ADDRESS (PART 1), 
PORT NUMBER (PART 1), 
IP ADDRESS (PART 2) 
AND PORT NUMBER 
(PART 2) 



1250 



REFER TO THE 
MANAGEMENT 
RANGE TABLE 



•1251 



1252 (j 



IP ADDRESS 
PART 1 ) 

INLY 



ARE THE IP 
ADDRESS 
(PART 1) 
AND THE IP^ 
ADDRESS 
(PART 2) 
INCLUDED 
IN THE 
MANAGE- 
MENT 
RANGE ? 



1253 



TO THE IP 
ADDRESS 
( PART 1 ) 



1254 



ISSUE get 



= IP AD- 
DRESS 
(PART 
2) ONLY 



1255 



:BOTH IP 
ADDRESSES 
(PART 1 
AND 

PART 2) 



TO THE IP 
ADDRESS 
(PART 2) 



1256 



ISSUE get 



1257 



TO THE IP 
ADDRESS 
(PART 1) 



1258 



ISSUE get 



YES 



NO 

ERROR 

? 




1260 



1261 



TO THE IP 
ADDRESS 
(PART 2) 




MOTHERS 



( END ) 



AN ERROR 
OCCURS 



1259 



1262 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 33 of 39 5,651,006 



( START ) 



FIG.37 

get ISSUE 



1270 



i 



YES 



IS THE 
STATUS OF 
THE 
CORRE- 
SPONDING 
IP ADDRESS | 
" Marginal " 
OR 

" Normal " 
AND IS 
THE 
SNMP 
SUPPORT- 
ED ? 



CONVERT THE 
MANAGEMENT 
OBJECT 
IDENTIFIER 



ISSUE A get 
REQUEST 



.1271 



.1272 



1273 YES 



YES 



-1275 



HAS THERE 
BEEN A 
RESPONSE 

? 



NO 
ERROR 

? 



RETURN THE 

OBTAINED 

RESULT 



[HO 



1276 



1274 



AN ERROR 
OCCURS 



INO 



AN ERROR 
OCCURS 



1277 



AN ERROR 
OCCURS 



1278 



( END ) 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent jui. 22, 1997 sheet 34 of 39 5,651,006 



( START ) 



1280 



FIG.38 

get -next PROCESSING 



YES 



IS THERE AN 
INDEX ? 



BREAK DOWN THE INDEX 
AND OBTAIN THE FOLLOWING 
INFORMATION : 
IP ADDRESS (PART 1), 
PORT NUMBER ( PART 1 ) , 
IP ADDRESS (PART 2) AND 
PORT NUMBER (PART 2) 



1281 



NO 



1282 



CALCULATE THE 
NEXT INDEX 



REFER TO THE 
MANAGEMENT 
RANGE TABLE 



1283 



1284 



P ADDRESS 
PART 1 ) 
ONLY 



ARE THE IP 
ADDRESS 
(PART 1) 
AND THE IP\ 
ADDRESS 
(PART 2) 
INCLUDED 
IN THE 
MANAGE- 
MENT 
RANGE ? 



1285 



TO THE IP 
ADDRESS 
(PART 1) 



1286 



ISSUE 
get • Next 



: IP AD- 
DRESS 
(PART 
2) ONLY 



1287 



1288 



:BOTH IP 
ADDRESSES 
(PART 1 
AND 

PART 2) 



TO THE IP 
ADDRESS 
(PART 2) 



ISSUE 
get - Next 



1289 



TO THE IP 
ADDRESS 
(PART 1) 



1290 



ISSUE 
get - Next 



YES 



NO 

ERROR 




1292 



1293 



= OTHERS 



( ) 



AN ERROR 
OCCURS 



TO THE OTHER 
ADDRESS OF 
THE TCP 
CONNECTION 

1291 
1294 




08/26/2003, EAST Version: 1.04.0000 



U.S. Patent Jul. 22, 1997 Sheet 35 of 39 



5,651,006 



FIG.39 

CALCULATION OF THE NEXT INDEX 



( START) 



YES ( HEADER ) 



NO INDEX 
ASSIGNED ? 



1300 



1 NO 



RETRIEVE THE MANAGE- 
MENT RANGE TABLE 
SEQUENTIALLY, AND SET 
THE IP ADDRESS THE 
STATUS OF WHICH IS 
M Marginal " OR " Normal " 
AND THE ENTRY OF 
WHICH SUPPORTS THE 
SNMP, TO THE IP 
ADDRESS ( PART 1 ) 



— 1301 



SET " 0 " TO THE PORT 
NUMBER ( PART 1 ) 



SET " 0 : 0 . 0 . 0 " TO THE 
IP ADDRESS ( PART 2 ) 



SET " 0 " TO THE PORT 
NUMBER ( PART 2 ) 



RETRIEVE THE 
MANAGEMENT RANGE 
TABLE SEQUENTIALLY, 
AND SET THE IP 
ADDRESS NEXT TO THE 
IP ADDRESS ( PART 1 ) 
THE STATUS OF WHICH 
IS " Marginal 0 OR " Normal 
AND THE ENTRY OF 
WHICH SUPPORTS THE 
SNMP, TO THE IP 
ADDRESS ( PART 1 ) 



1302 

1303 
1304 

1305 



( ) 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 36 of 39 



5,651,006 



( START ) 



FIG. 40 

get -next ISSUE 



YES 



IS THE 
STATUS OF 
THE CORRE- 
SPONDING 
IP ADDRESS 

Marginal " 
OR 

Normal " 
AND IS THE I 
SNMP 
SUPPORT- 
ED ? 



( ) 



CONVERT THE MANAGEMENT 
OBJECT IDENTIFIER 



ISSUE A get - next 
REQUEST 



YES 



ES 



IS THE 
OBTAINED 
RESULT 
THE VALUE 
OF 

tepConnState/ 



TCP 

CONNEC 
TION 

BETWEEN 
THE IP 
NODES ? 




1311 

1312 
1315 



RETURN THE 
OBTAINED 
RESULT 



1314 



1316 



ISSUE 
get - Next 



1313 



1317 



1310 



CALCULATE THE 
NEXT INDEX 



YES 



1319 




NO 



1318 



AN ERROR 
OCCURS 



CALCULATE THE 
NEXT INDEX 



—1321 



YES 




1322 



AN ERROR 
OCCURS 



1323 



1324 



08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 Sheet 37 of 39 



5,651,006 



CM 



CD 

LL 





08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 Sheet 38 of 39 



5,651,006 




08/26/2003, EAST Version: 1.04.0000 



U.S. Patent 



Jul. 22, 1997 



Sheet 39 of 39 



5,651,006 



( START ) 



FIG.43 

METHOD FOR DELETING THE SNMP TRAP 



1500 



REFER TO 
THE 

ENVIRON- 
MENT 
SETTING 
FILE 



1501 



LOOP 
UNTIL AN 
END 

REQUEST 
HAS BEEN 
RECEIVED 



( END ) 



1502 



SECURE A 
BUFFER 



1503 



LOOP 

BETWEEN 

THE TIME 

INTERVAL 

OF THE 

TRAP 

RELAY 



1508 



BUILD UP 
THE SUB- 
MANAGER 
EXTENSION 
TRAP 



1509 



ISSUE THE 
SUB- 
MANAGER 
EXTENSION 
TRAP TO 
THE 

INTEGRA- 
TION 

MANAGER 
( RELAY ) 



1510 



RELEASE 

THE 

BUFFER 



1504 




1505 



REFER TO 
THE IP 
ADDRESS 
AND THE 
INDEX IN 
THE 

MANAGE- 
MENT 
RANGE 
TABLE 



^1506 YES 


^1507 


IS THE / 


STORE THE 


RECEIVED / 


INDEX AND 


SNMP / 


THE SNMP 


TRAP THE / 


TRAP IN 


ONE / 


THE 


ISSUED / 


BUFFER 


BY THE ( 




AGENT \ 




WITHIN \ 




THE \ 




MANAGE- I 




MENT 




RANGE ? I 





08/26/2003, EAST Version: 1.04.0000 



5,651 

1 

HIERARCHICAL NETWORK 
MANAGEMENT SYSTEM 

BACKGROUND OF THE INVENTION 

5 

The present invention relates to a hierarchical network 
management system, and relates more particularly to a 
hierarchical network management system which hierarchi- 
cally manages network resources by agents, sub-managers 
and an integration manager and which uses SNMP (Simple 1Q 
Network Management Protocol) as a communication pro- 
tocol among them. 

In general, a management system of a communication 
network is structured by two types of sub-systems, managers 
and agents. A manager manages and controls network 15 
resources in agent unit An agent manages and controls 
management objects such as structure information and status 
information in resource unit of the communication network. 

There exist two international standards relating to man- 
agement of communication networks, IAB (Internet Activi- 20 
ties Board) management standard and OSI (Open Systems 
Interconnection) management standard. In the networks 
which use these management standards, their network 
resources are being managed in the following manner. 

(1) Network management systems which use the manage- 25 
ment standard 

When a communication network becomes large scale, the 
communication network is divided into a plurality of com- 
munication networks (hereinafter to be referred to as "sub- 
networks"), and a manager and agents are provided for each 30 
sub-network so that network resources of each sub-network 
are managed. 

In this case, in carrying out resource management based 
on the IAB management standard, an SNMP (Simple Net- 
work Management Protocol) is used. The standard relating 35 
to the SNMP is prescribed by RFC 1157, "A Simple Net- 
work Management Protocol". 

(2) Hierarchical network management system which uses 
both the OSI management standard and the IAB manage- 
ment standard 40 

A sub-manager manages each LAN (Local Area Network) 
based on the IAB management standard, and the sub- 
manager and its higher level integration manager manages 
the network resources based on the OSI management 
standard, as described in 'Integrated OSI Network Manage- 45 
ment for Distributed LAN Domains", Miyauchi et aL Infor- 
mation Processing Society of Japan, June 1993 issue, pp. 
1426-1440, hereinafter to be referred to as Reference lit- 
erature (1)". 

Reference literature (1) proposes to achieve hierarchical 50 
network management by combining both the OSI manage- 
ment and the SNMP management. In other words, in this 
network, the sub-manager manages the network resources 
according to the IAB management standard, converts this 
management to management based on the OSI management 55 
standard and transfers the converted management to the 
integration manager. The integration manager then manages 
all of the resources of the network. 

In managing a large-scale network, it is certainly effective 
to manage the network by a hierarchical structure from the 60 
viewpoint of deleting management packet and simplifying 
the manager. 

However, no consideration is given to hierarchical man- 
agement in the above-described network management sys- 
tem which uses the SNMP of the IAB management standard. 65 
Accordingly, even if a sub-manager is provided between the 
manager and the agents, it is not possible to achieve hier- 
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archical management if the structure of management infor- 
mation to be transmitted between the manager and the 
sub-manager and the method for focusing the management 
information are not completed. In other words, one problem 
is that it is not possible to achieve a hierarchical network 
management system for managing and controlling a group 
of agents. 

In this case, according to the standard of SNMPv2 (SNMP 
version 2), it is possible to notice an event from one manager 
to another manager. However, no consideration is given to 
hierarchical management in SNMPv2 as is the case with the 
SNMP. Accordingly, even if a sub-manager is provided 
between the manager and the agents, it is not possible to 
achieve the hierarchical management if the structure of 
management information to be transmitted between the 
manager and the sub-manager and the method for focusing 
the management information are not completed. 

On the other hand, in the OSI management system 
described in reference literature (1), the sub-manager should 
have both communication service of the OSI standard for 
achieving the OSI management standard and communica- 
tion service of the IAB standard for achieving the IAB 
management standard, so that there is a problem that the 
sub-manager becomes large in scale. 

In the LAN, communication service of the IAB standard 
is used, and it is a normal application of the communication 
network that communication service of the IAB standard is 
used between LANs. Accordingly, in the management sys- 
tem described in reference literature (1), it is necessary to 
use the OSI management standard although the IAB man- 
agement standard is used in a WAN (Wide Area Network), 
There is also a problem that the sub-manager is large in 
structure. 

Further, when the integration manager hierarchically 
manages the communication network, which is managed by 
a plurality of management standards, by integrating the 
communication network, it is necessary to give advance 
consideration to the agency and distribution, etc., for reduc- 
ing the load of conversion of management information and 
the load of the integration manager. However, no consider- 
ation is given to the agency, decentralization, etc., in man- 
agement system of the reference literature (1). Therefore, 
there is a problem that, as the network becomes larger in 
scale, the number of management packets which are used at 
the time of exchanging management information between 
the integration manager and the sub-manager increases. 

SUMMARY OF THE INVENTION 

It is a first object of the present invention to provide a 
hierarchical network management system which can hierar- 
chically manage a large-scale communication network by 
sub-managers of a simple structure based on an SNMP of the 
IAB management standard. 

It is a second object of the present invention to provide a 
hierarchical network management system which can trans- 
mit management information between an integration man- 
ager and sub-managers based on a small volume of man- 
agement packets and which can manage a large-scale 
communication network with low traffic and at low cost 

In order to achieve the first object, the present invention 
is characterized in that, basically, an SNMP is used as a 
communication protocol between an agent and a sub- 
manager and between a sub-manager and an integration 
manager, respectively, and that a periodical collecting unit is 
provided within a sub-manager which periodically collects 
management objects of a range of self-management through 
agents which belong to the same management range and 



08/26/2003, EAST Version: 1.04.0000 



5,651,006 

3 4 

which causes a sub-manager to post to the integration FIG. 4 is an explanatory diagram for showing an example 

manager the collected information at a reference request of the definition (part 1) of the periodical collection MIB 

from the integration manager. In this system, a sub-manager which is a sub-manager extension MIB. 

behaves as a manager to its agents and behaves as an agent FIG. 5 is an explanatory diagram for showing an example 

to the integration manager. 5 of the definition (part 2) of the periodical collection MIB 

In order to achieve the second object, the present inven- which is a sub-manager extension MIB. 

tion is characterized in that a sub-manager concentrates a FIG. 6 is an explanatory diagram for showing an example 

plurality of information from each agent which is managed of the definition (part 3) of the periodical collection MIB 

by a plurality of identifiers at a reference request from the which is a sub-manager extension MIB. 

integration manager and posts the concentrated information 10 pj^ 7 j s m explanatory diagram for showing an example 

to the integration manager by using an SNMP as a commu- of me definition (part 1) of the real-time collection MIB 

nication protocol. which is a su b-manager extension MIB. 

According to the above unit, a periodical collecting unit pjQ 8 is &n cxp ianatory diagram for showing an example 

within a sub-manager periodically collects management of me definition (part 2) of the real-time collection MIB 

objects of a self-management range through agents which 15 which is a su b-manager extension MIB. 

belong to the same management range and posts the col- mQ 9 {$ ^ cx lanat ^ for showing m cxamplc 

lected informauon to the integration manager at a reference Qf ^ ^tftoa ^ 3) of ^ collection ^ 

request from the integration manager. whkQ - s a w|HI1|inager cxtcnsion MrB , 

?j^ aS ^* CC ° U ^ 20 FIG. 10 is an explanatory diagram for showing an 

called MIB (Management Information Base) which is a set k of ^ definition Qf a extension tapt 

of a plurahty of management objects expressed in a tree correspondence table 

structure, is accessed at a reference request from the mte- / kKJ ' 1X A 7 • ~. t =>iiuwmg a ^ c 73 _7 

. inu^^n of management objects for converting from the MIB-EL to a 

gration manager and is posted to the integration manager. t & , J . _ 0 

xtr^ *u u a -u a ^ ^ •* • ui ♦ t sub-manager extension MIB. 

With the above-described structure, it is possible to hier- „ ° . . t „ 

archicany manage a large-scale convocation network 25 ^0 12 is an explanatory dugram for showing the 
based on a single protocol called an SNMP of the IAB contents of smglpNodeContext which is a sub-manager 
standard and that it is possible to simplify the structure of a extension MIB. 

sub-manager because of the simple protocol. 13 1S ™ explanatory diagram for showing the 

, , . . , . contents of smgSumTcpContext which is a sub-manager 

A sub-manager concentrates a plurality of management 30 . tuttr 

objects from each agent which is managed by a plurality of CX ™ 10 ^ . ' . ^ ^ . ^ 

identi^ersandpostsmeconcentratedresulttotheintegrauon ™. M « * *agramfor showing a conespondence table 

manager. Accordingly, it is possible to transmit management of * e P erAodlcal coUectlOD MIB to be totaled 

information between the integration manager and a sub- ^G. 15 is an explanatory diagram for showing an 

manager with a small volume of management packets and 35 example of the environment setting file, 

that it is possible to reduce the load of the integration FKJ- 1* is an explanatory diagram for showing an 

manager. Further, it is possible to manage a large-scale example of the contents of the management range table, 

communication network with low traffic and at low cost FIG. 17 is an outline PAD diagram of the monitoring 

A network manager at the integration manager side can method (main) of a management range, 

confirm agent structure information and status information 40 FIG. 18 is an outline PAD diagram of the initial setting of 

of a sub-manager management range by referring to the a management range. 

periodical collection MIB of the sub-manager to meet an FIG. 19 is an outline PAD diagram of the monitoring of 

application. a management range. 

Further, when a sub-manager collects management FIG. 20 is an outline PAD diagram of a router determi- 

objects in real time and posts the collected management 45 nation. 

objects to the integration manager, the integration manager FIG. 21 is an outline PAD diagram of a ping processing, 

can accept the latest status of a sub-manager management jqQ m 22 is an outline PAD diagram of a total processing, 

range with small resources (CPU power and memory FIG. 23 is an updated outline PAD diagram of a manage- 

capacity) and with small number of management packets. mont range 

Further, when the integration manager manages TCP 50 nGt 24 is an outline PAD diagram of an updating 

connection information of sub-manager management range processing. 

as a real-time collection MIB, there is an effect that it is nQ ^ ^ an Mc pAD ^ of fln ^ ocaXion 

possible to specify an IP node and service of high traffic ^ ^ coffimunication ^ Mon 

within a management range of a sub-manager 10 with small _ . . _ A _ „ . „ 

™~fs™ *u 0 ir.n^riL r«ona«Ar « FIG. 26 is an outline PAD diagram of an allocation 

operation of the integration manager. 55 . 7 L . 

r method in the sub-manager agent function. 

BRIEF DESCRIPTION OF THE DRAWINGS piG. 27 is an explanatory diagram for showing an 

FIG. 1 is a system structure diagram for showing one example of the contents of the periodical collection MIB 

embodiment of the communication network management value management table. 

system in which an integration manager, sub-managers and ^ FIG. 28 is an outline PAD diagram of the collection data 

agents are arranged. base management function. 

FIG. 2 is a logical relation diagram for showing a logical FIG. 29 is an explanatory diagram for showing an 

relationship between the integration manager, sub-managers example of the graph display in the integration manager of 

and agents shown in FIG. 1. a collected value which is the periodical collection MIB. 

FIG. 3 is a functional structure diagram for showing a 65 FIG. 30 is an explanatory diagram for showing an 

detailed structure of a sub-manager which is a key element example of the TCP connection to which the concentration 

of the present invention function is applied. 
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FIG. 31 is an explanatory diagram for showing the format and 10c through the WAN4 and the sub-managers IQa, lUb 

of the index and value of tcpConnState of MIB-IL and 10c is connected to the LAN3. In other words, the 

FIG. 32 is an explanatory diagram for showing the format integration manager 50 for hierarchically managing all of 

of the index and value of smgSumTcpContext of the real- resources of the network is connected to the LAN3. 

time collection MIB, 5 FIG. 2 is a diagram for showing the logical relationship of 

FIG. 33 is an explanatory diagram of the conversion ^ a S cnts * sub-managers and the integration manager, 

between the tcpConnState of MIB-I1 and smgSumTcpCon- Between the sub-manager 10a connected to the LAN1 and 

text of the real-time collection MIB. ^ ^ ents 20fl " 1 md 20a ' 2 > ^ management objects are 

~ A : * . . » _ . . managed by using the SNMP of the IAB management 

FIG. 34 is an explanatory diagram for showing a sequence in * A T ™£> n «. ♦ ^ - i ,v 

* a „ i ii *; xmtt> 10 standard and ICMP (Internet Control Message Protocol). 

of the index of the real-time collection MIB. tj^„ flwk olll - A < * i j j m 

, Between the sub-manager 10<z and the agent-unloaded IP 

FIG. 35 is an outline PAD diagram of the concentrating node 30a, the management objects are managed by using the 

method (main) of a management range. ICMP. Ib the sub-manager 10a, a collection MIB data base 

FIG. 36 is an outline PAD diagram of the concentrating 170a for holding a set of a plurality of management objects 

method (get processing) of a management range. 15 that have been collected through the agents of the manage- 

FIG. 37 is an outline PAD diagram of the concentrating ment range in a format called the MIB, (Management 

method (get issuing) of a management range. Information Base) which is expressed in a tree structure, is 

FIG. 38 is an outline PAD diagram of the concentrating connected, 

method (get-next processing) of a management range. Similarly, between the sub-manager 10c connected to the 

FIG. 39 is an outline PAD diagram of the concentrating 20 LAN2 f d u ±e ^ * e ^gement objects are 

method (next index calculation) of a management range. * " sm & * e B SNMP °[ ***** management 

™ Ati . 4l . t\ A> c *iT Zl- standard and the ICMP. Between the sub-manager 10c and 

im 40 is an outline PAD diagram of the concentrating theage^o^jp^d^o^ the managemenf objects are 

method (get-next issuing) of a management range. by ug . me JCMp / To me ^ j ^ c % 

FIG. 41 is a conversion diagram for converting an SNMP 25 coUecuonMTO data base 170c for holding a set of a plurality 

trap to a sub-manger extension trap. of management objects that have been collected through the 

FIG. 42 is a conversion diagram for converting an SNMP agents of the management range in a format called the MIB 

trap to a sub-manger extension trap. (Management Information Base), (hereinafter to be referred 

FIG. 43 is an outline PAD diagram of the deleting system to as *the MIB format") which is expressed in a tree 

of an SNMP trap. 30 structure, is connected. 

DESCWIION OF -niEPREFERRED connected to the integration manager 50 in a similar logical 

EMBODIMENTS relationship. 

One embodiment of the present invention will be FIG. 3 is a functional block diagram for showing one 

explained in detail with reference to the drawings. 35 embodiment of the internal structure of the sub-manager 10, 

FIG. 1 is a system structure diagram for showing one which is structured by the following functional module: 

embodiment of the communication network to which the (1) communication control function 100 

present invention is applied. Aplurality of LANs 1, 2 and 3 (2) management range monitoring function 110 

are connected by a WAN (Wide Area Network) 4. ^ (3) collection data base management function 120 

Among these LANs, to the LAN1, a plurality of agents (4) self-agent function 130 

20o-l and 20a-2 for managing and controlling management (5) sub-manager agent function 140 

objects such as structure information and status information (6) concentratiori fr nct ion 150 

in network resource unit and an agent-unloaded IP (Internet n ^ _ 1 *n 

Protocol) node 30* arc connected. Further, through the AK f ^ ^ 

QnAntt 7 i ! on<4 ~ ™\ * "7* * Z. ~™ J« 45 Details of each function are as described below. 

25 lln ,k ^ 1 (D communication control function 100 

c^rSS nmagCment ° bjCCtS WltlUn te LAN1 1S Under the IAB management standard, the protocol for 

w , , ... network management is called SNMP. This standard is 

To the LAN2, a plurality of agents 20Z>-1 and 20b-2 for prescribed by the RFC 1157, "A Simple Network Manage- 

managing and controlling management objects such as 50 ment Protocol". 

structure information and status information in network The corresponding communication control unit 100 
resource unit are connected Further, a sub-manager 10* for rcocivcs m SNMP rcqucst from the integration manager 50 
managing and controlling the management objects under the and ^ ^.m^ager io itself to the corresponding sub- 
management of the agents 20&-1 and 20*k2 is connected to manager and an SNMP trap 

the LAN2. Further, an agent 20c and an agent-unloaded IP 55 ^ S NMP request is a request from the integration 

node 30a are connected to the LAN2 and a sub-manager 10c manager 50 to the sub-manager for obtaining management 

for managing and controlling the management objects under ob jects, and a request from the sub-manager 10 to the agent 

the management of the agent 20c is also connected to the 2 0 for obtaining management objects. 

LAN2, An SNMP request that has been received within the 

In other words, in the LAN2, the management objects are eo coirmiunication control unit 100 is posted to the self-agent 

managed by the two sub-managers 10b and 10c. function 130 or to the sub-manager agent function 140 

On the other hand, to the LAN3, a plurality of agents 20-1 according to the management object identifier which exists 

and 20-2 are connected. Further, an integration manager 50 within the protocol, and the result of the requested work 

for managing and controlling the management objects under done is responded to the integration manager 50 or to the 

the management of the agents 20-1 and 20-2 and for 65 sub-manager 10 itself which are the SNMP requesters. A 

managing and controlling the management objects under the received SNMP trap is posted to the trap management 

management of the WAN4 and the sub-managers 10a; 10b function 160. 
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(2) management range monitoring function 110 

By referring to the environment setting file 180 assigned 
by the network manger of the sub-manager 10, the manage- 
ment range monitoring function 110 obtains the range of the 
IP address which has been assigned as the management 5 
range of the sub-manager 10. The management range moni- 
toring function 110 periodically issues an SNMP request and 
an ICMP echo request for obtaining a specified management 
object defined by the MIB-H, to a specified IP address group 
(regardless of whether an agent is loaded or not), and obtains 10 
an SNMP response and an ICMP echo response which are 
the result of the requests. 

In this case, a polling interval of the SNMP request and 
the ISMP echo request to be periodically issued and a 
community name to be described on the SNMP protocol are 15 
obtained by referring to the environment setting file 180. 

The management range monitoring function 110 produces 
information of the MIB format from the result periodically 
obtained, stores the information of the latest MEB format in 
the memory, delivers this information to the collection data 20 
base management function 120 and makes the collection 
data base management function 120 to store the delivered 
information in the collection MIB data base 170. 

The management range monitoring function 110 also 
enables the concentration function 150 to refer to the infor- 25 
mation regarding the IP address and status of the manage- 
ment range and information of whether an agent is loaded or 
not 

Further, the management range monitoring function 110 
enables the trap management function 160 to refer to the 30 
information regarding the IP address of the management 
range and index numbers. 

When there has been a change to the information which 
structures a value of the collection MIB such as an addition 
or a deletion of the IP node of the management range, the 35 
management range monitoring function 110 issues a sub- 
manager extension trap for posting the change of the infor- 
mation to the integration manager 50. 

The standard of the MIB-II is prescribed in RFC 1213, 
'Management Information Base for Network Management 40 
of TCP/IP Based Internets: MB-IT. 

(3) collection data base management function 120 
When information which constitutes a value of the col- 
lection MIB has been inputted from the management range 
monitoring function 110, the collection data base manage- 45 
ment function 120 stores this information in the collection 
MIB data base 170. When a request for obtaining the 
collection MIB value has been inputted from the sub- 
manager agent function 140, the collection data base man- 
agement function 120 builds each information that structures so 
the value of the collection MIB into a management object 
format and responds the collection MIB value to the sub- 
manager agent function 140. 

(4) self -agent function 130 

The self-agent function 130 manages the host in which the 55 
sub-manager 10 exists. An SNMP request to the MIB-II and 
the agent extension MIB from the integration manager 50 
and the sub-manger 10 itself is inputted to the self-agent 
function 130 from the communication control function 100, 
and the self-agent function 130 outputs the requested SNMP 60 
to the communication control function 100. 

The environment setting file 180 refers to the self -agent 
function 130 for a community name (a password for decid- 
ing whether to make a response to an SNMP request or not). 

(5) sub-manager agent function 140 65 
An SNMP request to the sub-manager extension MIB 

from the integration manager 50 is inputted from the com- 



munication control function 100, and the sub-manager agent 
function 140 allocates the destination from which the 
requested SNMP is to be obtained based on the management 
object identifier described in the protocol of the SNMP 
request 

To be more specific, according to the present invention, in 
order to provide to the integration manager 50 the manage- 
ment information that has been collected or concentrated by 
the sub-manager 10, the sub-manager extension MIB which 
includes the collection MEB and the real-time collection 
MIB is defined. 

The periodical collection MIB is the MEB of the manage- 
ment information which has been periodically collected by 
the sub-manager 10 from the IP node group of the manage- 
ment range. 

The real-time collection MIB is the concentration in the 
MB3 format of the management object information which 
has been prepared by the sub-manager 10 for the sub- 
manager to respond to the integration manager 50, by 
real-time collecting and concentrating (deleting or process- 
ing unnecessary information) the management object infor- 
mation of the management range at the reference request of 
the integration manager 50. 

In the case of a reference request to the periodical 
collection MIB, the sub-manager agent function 140 
requests the collection data base management function 120 
to obtain the MIB value and the sub-manager agent function 
120 obtains the result from the collection MIB data base 
170. 

In the case of a reference request to the real-time collec- 
tion MIB, the sub-manager agent function 140 requests the 
concentration function 150 to obtain the MIB value, and 
obtains the result from the concentration function 150. 

The sub-manager agent function 140 outputs the obtained 
result to the communication control function 100. 

The environment setting file 180 refers to a conununity 
name (a password for deciding whether to respond to an 
SNMP request or not) in the sub-manager agent function 
140. 

(6) concentration function 150 

When a request for obtaining the real-time collection MIB 
value has been inputted from the sub-manager agent func- 
tion 140 to the concentration function 150, the concentration 
function 150 issues an SNMP request to the IP node group 
which is loaded with an agent of the management range. 
After a response to the request has been received, the 
concentration function 150 carries out a concentration pro- 
cessing and returns the concentrated MIB value to the 
sub-manager agent function 140. 

The environment setting file 180 refers to a community 
name described in the protocol at the time of issuing the 
SNMP request. 

(7) trap management function 160 

When the SNMP trap is posted to the trap management 
function 160 from the communication control function 100, 
the trap management function 160 summarizes a plurality of 
SNMP traps posted within a predetermined time as one 
sub-manager extension trap and relays the sub-manager 
extension trap to the integration manager 50. 

The environment setting file 180 refers to a time interval 
for issuing the sub-manger extension trap and a community 
name and others described in the protocol, in the trap 
management function 160. 

The logical structure of the sub-manager extension MIB 
which is the main element of the present invention, the 
method of determining and the method of monitoring the 
management range of the sub-manager, the method of 
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allocating an SNMP request that has been received by the 
sub-manager, the method of managing the collection MB, 
the method of concentrating the collection MIB and the 
method of managing the SNMP trap will be explained in 
detail. 

(1) logical structure of the sub-manager extension MIB 

According to the IAB management standard, the logical 
structure of the management object is usually defined by a 
virtual data base called a management information base. 
This management information base is called MIB. 

A syntax for describing the MIB and a method for 
identifying the instance of a management object are pre- 
scribed in RFC 1155, "Structure and Identification of Man- 
agement Information for TCP/IP-based Internets" and RFC 
1212, "Concise MIB Definitions". 

The standard agent 20 is loaded with a management 
object which is prescribed in the MIB-IL 

The sub-manager 10 issues an SNMP request and an 
ICMP echo request for obtaining a value of a specified 
MIB-II from the IP node group of the management range, 
and obtains a value of the sub-manager extension MIB from 
a result of collection of the response to the requests. 

The sub-manager extension MIB is structured by the 
periodical collection MIB and the real-time collection MIB. 

The periodical collection MEB is the MIB which is 
prepared from the management information that has been 
periodically collected by the sub-manger 10 from tbe IP 
node group of the management range. This data base is 
structured by table type management object identifiers con- 
sisting of a plurality of entries and non-table type manage- 
ment object identifiers. 

A table-type management object identifier has an entry in 
IP node unit of the management range, and structure infor- 
mation (IP address, host name, presence or absence of the 
loading of an agent, identification flag of the IP router, etc.) 
of the management range and status information such as the 
IP status, response time of the ping (ICMP echo request 
packet), etc. are held in each entry. 

When a reference request has been received from the 
integration manager 50, a method is used for reducing the 
number of management object identifiers to be returned, by 
putting the entry consisting of a plurality of information into 
an information unit which includes an index portion and a 
context portion. 

A non-table type management object identifier expresses 
the information of the contents of each of the structure 
information and status information of the table type man- 
agement object totaled by the number of the IP nodes. 

A unit for totaling information for giving the total infor- 
mation to the integration manager 50 is provided in the 
sub-manager 10. 

On the other hand, the real-time collection MIB is the 
concentration in the MIB format of the management infor- 
mation which has been prepared by the sub-manager 10 for 
the sub-manager to respond to the integration manager 50, 
by real-time collecting and concentrating (deleting or pro- 
cessing unnecessary information) the management informa- 
tion of the management range at the reference request of the 
integration manager 50. 

The sub-manager 10 receives an SNMP request from the 60 
integration manager 50 and from the sub-manager itself. 
This is because the sub-manager itself can be included in the 
management range of the sub-manager 10. Particularly, 
when the sub-manager 10 has received a reference request of 
the real-time collection MIB from the integration manager 
50, the sub-manager 10 issues an SNMP request to the 
sub-manager itself, and responds the result of the SNMP 
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after concentration. Therefore, the sub-manager 10 is struc- 
tured to be able to carry out parallel processing of a plurality 
of SNMP requests. 

Examples of the definition of the periodical collection 
MIB which is the sub-manager extension MIB are shown in 
FIGS. 4 to 6, examples of the definition of the real-time 
collection MIB are shown in FIGS. 7 to 9, and an example 
of the sub-manager extension trap is shown in FIG. 10. 

In the definition examples of the periodical collection 
MIB in FIGS. 4 to 6, the following definition examples are 
shown: 

(1) number of IP nodes to be managed 

(2) number of nodes which are in critical situation with 
the sub-manager 

(3) number of nodes which can communicate with the 
sub-manager but in which there exists a TCP/IP inter- 
face that is not operating 

(4) number of nodes in which all the TCP/IP interfaces are 
operating 

(5) number of routers which are within the management 
range of the sub-manager 

(6) number of nodes which are loaded with SNMP within 
the management range of the sub-manager 

(7) a list of information relating to the IP node of the 
management range of the sub-manager 

(8) entry which includes information for each IP of the 
management range 

In the definition examples of the real-time collection MIB 
in FIGS. 7 to 9, the following definition examples are 
shown: 

(1) a list of the TCP connection within the management 
range of the sub-manager 

(2) IP address at which the TCP connection is opened 

(3) port number used by the node which is defined by 
smgSumTcpServerlpAddress 

(4) IP address at which the TCP connection is opened (the 
other address defined by smgSumTcpServerlpAddress) 

(5) port number used by the IP node which is defined by 
smgSumTcpClientlpAddress 

(6) entry of the TCP connection information which is 
opened by the IP node of the management range 

In tie definition examples of the sub-manager extension 
trap in FIG. 10, the following definition examples are 
shown: 

(1) a trap for posting an addition of a system 

(2) a trap for posting a deletion of a system 

(3) a relay trap 

FIG. 11 shows a correspondence table 190 for converting 
the name of a management object of the MJB-II (hereinafter 
to be referred to as an "MIB-n object'*) which has been 
periodically and real-time collected by the sub-manager 10 
into a management object name of the extension MIB. When 
MIB-II objects have been periodically and real-time col- 
lected from an agent which is loaded with management 
objects of the MIB-II in a standard manner, the names of the 
MIB-II objects are converted to names of management 
objects of the extension MIB. 

FIG. 12 shows contents 200 of smgJpNodeContext which 
is a management object of the periodical collection MIB 
after conversion. As shown in FIG. 12, smglpNodeContext 
is structured by an IP address 210, a host name 220, a status 
230, a ping response time 240, SNMP support information 
250 and router information 260. 

When the integration manager 50 periodically collects a 
management object structured this way from the sub- 
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manager 10 and makes a display of the management object, each set. For example, the management address range 440a 

it is possible to display in one row a plurality of information indicates that an IP address can be assigned from 

relating to one agent or an IP node, so that it is possible to 200.10.20.1 to 200.10.20.70. 

easily confirm the state of one agent or the IP node. The community name of the management address range 

FIG. 13 shows contents 300 of smgSumTcpContext 5 44° * used when the sub-manager 10 issues an SNMP 

which is a management object of the real-time collection request to the agent of the management range. 

MB. As shown in FIG. 13. smgSumTcpContext is struc- ^ 1? default Value) ? f ^ e PO^g interval for 

tured by an IP address (part 1) 310, port number (part 1) 320, Periodically collecting managemen objects 

a status (part 1) 330 an IP address (part 2) 340. a port *? fiv . c for cxam P le ' M 

' f! , \ ■ „ time is set to one second, for example. An initial value of the 

number (part 2) 350, a status (part 2) 360 and a service name 10 ^ rclay ^ fa ^ ^ fa ^ 

. . . M . „. „ « . FIG. 16 is a diagram for showing the format of the 

When the integration manager 50 penodically collects a range table 500 to be provided inside the 

management object structured this way from the sub- management range monitoring function 110. The manage- 

manager 10 and makes a display of the management object, ment ^le 500 is structured by a control unit and a 

it is possible to display in one row a plurality of information 15 plurality of entries, and a maximum entry number is the 

relating to one TCP connection, so that it is possible to easily same as the value assigned by the management range 

confirm the state of one TCP connection. number 430 in FIG. 15. 

In the periodical collection MIB, a management object The control unit is structured by an area for storing the 

name (identifier) to be used for totaling values of the obtaining community name 510a, etc. The contents to be 

periodical collection MIB is prepared as shown by a corre- 20 taken into this control unit from the environment setting file 

spondence table 400 in FIG. 14. The periodical collection 180 will be explained below. 

MBB is totaled according to the correspondence table 400. The obtaining community name 400 is set to the obtaining 

An example of totaled management objects that have been community name 510a, the setting conornunity name 410 is 

collected by the integration manager 50 at every ten minutes set to the setting community name 510, the management 

interval is displayed in a graph as shown in FIG. 29. 25 range number 430 is set to the management range number 

(2) method of deterrnining and method of monitoring a 510^ and the destination number assigned by the trap 

sub-manager management range destination 420 and the destination IP address are set to the 

smgCreateSystemTrap in FIG. 10 defines a sub-manager trap destination number 510a" and the trap destination table 

extension trap to be issued when an IP node has been added address 510e respectively. Other contents will be explained 

to a sub-manager management range. An extension trap 30 with reference to FIGS. 17 to 24. 

number is "1", and a corresponding index number 520a in FIG. 17 shows an outline of the main processing of the 

a management range table 500 shown in FIG. 16 is assigned management range monitoring function 110. At first, the 

to a variable list (Variable-bindings). management range is initialized (step 600) and the process- 

smgDeleteSystemTrap in FIG. 10 defines a sub-manager ing is looped until a request for ending is received (step 610). 

extension trap which is to be issued when an IP node has 35 During this period, monitoring of the management range 

been deleted from the sub-manager management range. An (step 620), total processing (step 630) and updating of the 

extension trap number is **2", and a corresponding index management range (step 640) are carried out sequentially, 

number 520a in the management range table 500 is assigned FIG. 18 shows an outline of the initialization of the 

to the variable list (Variable-bindings). management range (step 600). The above-described envi- 

HG. 15 is a diagram for showing the format of the 40 ronment setting file 180 is referred to and the management 

environment setting file 180 which is used for determining range table 500 is set (steps 650 and 651). 

the management range and monitoring range of a sub- In order to set only an existing IP address out of the IP 

manager. The environment setting file 180 includes an area addresses assigned to the management address range 440 to 

for storing an obtaining community name 400, a setting the IP address 5206 of the entry of the management range 

community name 410, a trap destination 420, management 45 table 500, the following processing is carried out At first, in 

range number 430, a management address range 440 and a order to obtain an IP address recognized by the sub-manager 

trap relay interval 450 respectively. 10, atNetAddress which is an address conversion group of 

The obtaining community name 400 is the name used for the MIB-II is obtained from the self-agent function 130 (step 

a certification when a request for obtaining an SNMP has 652). 

been received. This name is also used when the sub-manager 50 The value of the obtained atNetAddress shows a relation- 

10 issues a sub-manager extension trap. ship between the IP address and the physical address. A 

The setting community name 410 is the name used for a blank address 520 exists in the management range table 500, 

certification when a request for setting an SNMP has been and the processing loops during the period while the IP 

received. address of atNetAddress exists (step 653). 

The trap destination 420 is the other party IP address to 55 A decision is made whether the IP address of atNetAd- 

which the sub-manger 10 issues a sub-manager extension dress is included in the management address range 440 in 

trap, and the trap destination 420 can be assigned by a FIG. 15 (step 654), and a ping is issued to only the IP address 

plurality of number like trap destinations 420a and 4206. that is included (step 655). 

The management range number 430 is the information for A decision is made on the presence or absence of a 

assigning a maximum IP node number to be included in the 60 response of the ping (step 656)» and the IP address from 

management range of the sub-manager 10. which there has been a response is set to the IP address 5206 

The management address range 440 is the information for of the blank entry 520 of the management range table 500. 

assigning the IP address of an IP node which is within the A sub-manager extension trap for posting that an IP node has 

management range, a community name, a polling interval been added to the management range is issued to the 

and a time-out time. The management address range 440 can 65 integration manager 50 (step 658). 

be assigned by a plurality of sets like 440a and 4406 as Next, a community name relating to a corresponding IP 

shown in FIG. 15. An IP address range can be assigned in address, a polling interval and time-out time are obtained 
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from the management address range 440 of the environment 520h of the ping of the corresponding entry 520 is set (step 

setting file 180, and the community name 520c, the polling 713), the oldest time 520* when the response of the ping has 

interval 520tf and the time-out time 520e are set respectively finished is cleared (step 714), and a decision is made the 

(step 659). SNMP support information 520/ (step 715). 

Next, by referring to an /etc/host file (included in the 5 When the SNMP support information 520/ is "nonsnmp", 

information for each IP node in FIG. 6), the host name 520f "Normal" is set to the status 520g (step 716), and when the 

of the corresponding IP address 520£> is set (step 660). Then, SNMP support information 520/ is "snmp", '^Marginal" is 

"Normal" is set to the status 520g (step 661). set to the status 520g (step 717). 

FIG. 19 shows an outline of the monitoring of the When there has been no response to the ping (step 712), 

management range (step 620). 10 "Critical" is set to the status 520g of the corresponding entry 

By referring to the management range table 500 (step 520 (step 718), and the oldest time 520y when the ping 

670), the processing is looped by the number of entries 520 response finished is confirmed (step 719). 

to which the IP address 5206 is set When the oldest time 520/ exists (step 719) and when a 

During this period, the ping processing is carried out (step predetermined time (for example, a week) has passed (step 

672). A decision is made whether the IP addresses 5206 are 15 720), the contents 520a to 520* are deleted from the 

set to the corresponding entries 520 and whether the status corresponding entry 520 (step 721) and a sub-manger exten- 

520g is other than "Critical" or not (step 673), and an SNMP sion trap for posting that the IP node has been deleted from 

request for obtaining values (reference FIG. 11) of MIB-II the management range is issued to the integration manager 

(sysObjectID, ifNumber, ifType, ifOperStatus and 50 (step 722). 

ifForwarding) is issued to the IP nodes which meed the 20 When the oldest time 520i does not exist (step 719), the 

above conditions (step 674). current time is set (step 723). 

Next, a decision is made on the presence or absence of a FIG. 22 shows an outline of the total processing (step 

response to the SNMP request (step 675). If there has been 630). 

a response, "snmp" is set to SNMP support information 520/ At first, portions 510/ to 510* for counting the IP address 

of the corresponding entry 520 (step 676) and a router 25 numbers in the control unit of the management range table 

decision is made (step 677). . 500 are cleared, and the processing is looped by the number 

If there has been no response, "nonsnmp" is set to the of the entries 520 (step 732). A count-up processing (+1) is 

SNMP support information 520/ of the corresponding entry carried out under the following conditions only when the IP 

520 (step 678), and "host" is set to router support informa- address is set to a corresponding entry 520. 

tion 520* (step 679). 30 A count-up is carried out for sm^TotaiManageNo deNum- 

FTG. 20 shows an outline of the router decision (step 677). ber unconditionally (step 734), for srngTotalCriticalNode- 

As an initial setting, the **host" is set to the router support Number only when the status 520g is "Critical" (step 736), 

information 520* (step 690). A decision is made to a value for smgTotalMarginNodeNiimber only when the status 520# 

(reference FIG. 11) of ipForwarding of the MIB-ii (step is "Marginal" (step 737), for srn^otalNormalNodeNumber 

691), and if the value is "1" (gateway), the processing 35 only when the status 520 is "Normal" (step 738), for 

proceeds to step 692 and if the value is other than "1" (host) smgfTotalRouteNodeNumber only when the router support 

the processing proceeds to step 698. information 520* is 'Toute" (step 740), and for smgTotal- 

A decision is made to a value of ifNumber of the MIS-II SnmpSupportNodeNumbcr only when the SNMP support 

which shows an interface number (step 692), and if the value information 7420/ is "snmp" (step 742), respectively, 

is at least "2", the processing proceeds to step 693 and if the 40 If there is a difference between the number before the 

value is "1", formal" is set to the status S20g (step 697). totaling and the number after the totaling (step 743), the 

A decision is made whether there exist a plurality of difference information is stored in the collection data base 

interfaces in which the value of ifiype of the MIB-II is other management function 120 (step 744). 

than "24" (sofrwareLoopback) and whether all the values of FIG. 23 shows an outline of the updating of the manage- 

ifOperStatus of the MEB-II that show the status is "1" (up) 45 ment range (step 640). 

or not (step 693). If these conditions are met, "router" is set At first the operation is started after confirming that a 

to the router support information 520* (step 694) and predetermined time, for example, three hours , have passed 

"NorraaT is set to the status 520g (step 695). since the last updating (step 750). 

If these conditions are not met, Marginal" is set to the The processing is looped for only the IP address where a 

status 520g (step 696). 50 blank entry 520 exists in the management range table 500, 

If the value of ipForwarding of the MIS-II is other than the status 520# is other than "Critical" and the SNMP 

*T' (host) (step 691), a decision is made to the value of support information 520/ is "snmp" (step 751). 

ifNumber of the MIS-H which shows the interface number Next, an SNMP request is issued to the IP address 5206 

(step 698). If the value is at least "2", the processing of the corresponding entry, for obtaining atNetAddress of 

proceeds to step 699, and if the value is "1", "Normal" is set 55 the MIB-II (step 752). 

to the status 520g (step 702). When there has been a response to the SNMP request 

At the step 699, a decision same as that of the step 693 is (step 752), the processing is looped during the period when 

carried out If the conditions are met 4t Normal" is set to the the blank entry 520 exists and by the number of the IP 

status 520g (step 700), and if the conditions are not met, addresses obtained (step 754), and the updating processing 

"Marginal" is set to the status 520g (step 701). 60 is carried out (step 755). 

FIG. 21 shows an outline of the ping processing (step When there has been no response to the SNMP request 

672). (step 752), "Critical" is set in order to update the status 520g 

At first, response time S2Qh of the ping of the correspond- (step 756). 

ing entry 520 is cleared (step 710), a ping is issued to a FIG. 24 shows an outline of the updating processing (step 

specified IP address (step 711) and presence or absence of a 65 755). 

response to the ping is confirmed (step 712). When there has At first, a decision is made whether the IP address is the 

been a response to the ping (step 712), the response time one which does not exist in the IP address 5206 of the 
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management range table 500 and whether the IP address is 
included in the management address range 440 of the 
environment setting file 180 (step 760), and the following 
processing is carried out only when the conditions are met 

The IP address is set to the blank entry 520 (step 761) and 
a sub-manger extension trap for posting that the IP node has 
been added to the management range is issued to the 
integration manager 50 (step 762). 

By carrying out the above processing, the sub-manager 10 
can limit the number of IP nodes to be included in the 
management range and can monitor only the existing IP 
nodes. 

(3) method of allocating SNMP requests that have been 
received by the sub-manager 

The communication control function 100 receives SNMP 
requests from the integration manager 50 and the concen- 
tration function 150 of the sub-manager 10 and receives an 
SNMP trap from the agent 20. 

The sub-manager agent function 140 allocates the SNMP 
requests inputted from the communication control function 
100 based on management object identifiers and relays the 
allocated result to the collection MIB data base management 
function 120 or the concentration function 150. 

The main reason for providing the two agents of the 
self-agent function 130 and the sub-manager agent function 
140 is that it is necessary to process in parallel the SNMP 
request from the integration manager 50 and the SNMP 
request from the concentration function 150. To be more 
specific, based on the parallel processing of the SNMP 
requests, when SNMP requests have been received from the 
integration manager 50 to the real-time collection MIB of 
the sub-manager 10, it becomes possible for the concentra- 
tion function 150 to issue an SNMP request to the self-agent 
function 130 through the communication control function 
100 as an extension of the processing and to produce a 
real-time collection MIB value based on the result of the 
SNMP request and send a response of the SNMP to the 
integration manager 50. 

FIG. 25 shows an outline of the method of allocating the 
SNMP requests by the management object of the commu- 
nication control function 100. The communication control 
function 100 loops until an end request has been received 
(step 770). The data to be received by the communication 
control function 100 includes SNMP requests from the 
integration manger 50 and the concentration function 150 of 
the sub-manager 10, SNMP responses from the self-agent 
130 and the sub-manager agent function 140, and SNMP 
traps from the agents, and a decision is made which one of 
these data has been received (step 771). 

When an SNMP request has been received, a decision is 
made whether the object identifier is the sub-manager exten- 
sion MIB in order to allocate the SNMP request by the 
management object identifier within the protocol of the 
SNMP request (step 772). If the object identifier is the 
sub-manager extension MIB, this fact is posted to the 
sub-manager agent function 140 (step 773). If the identifier 
is not the sub-manager extension MIB. this fact is posted to 
the self-agent function 130 (step 774). 

On the other hand, when an SNMP response has been 
received, a response is made to the integration manager 50 
(step 775). 

When an SNMP trap has been received, this fact is posted 
to the trap management function 160 (step 776). 

FIG. 26 shows an outline of the method of allocation by 
the management object of the sub-manager agent function 
140. 

At first, the sub-manager agent function 140 loops until an 
end request has been received (step 780). 
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The data to be received by the sub-manager agent func- 
tion 140 includes an SNMP request from the communication 
control function 100 and a response of the result of the MIB 
value from the collection data base management function 
5 120 and the concentration function 150. Therefore, a deci- 
sion is made which one of these has been received (step 
781), 

When an SNMP request has been received, a decision is 
made whether this is a request for obtaining an MIB and 

10 whether the community name matches or not (step 782) . The 
coiifirmation of the community name is carried out by 
comparing the community name within the protocol of the 
SNMP request with the obtaining community name 400 
shown in FIG. 15. 

15 When the decision conditions of the above step 782 are 
met a decision of the operation is made (step 783). 

When the operation is get-next, the next assigned man- 
agement identifier is obtained, and this is set as the requested 
management identifier (step 784). Next a decision is made 

20 whether the object identifier is the periodical collection MEB 
or the real-time collection MIB (step 785). When the object 
identifier is the periodical collection MIB, this fact is posted 
to the collection data base management function 120 (step 
786). When the object identifier is the real-time collection 

25 MIB, this fact is posted to the collection function (step 787). 
If the decision conditions of the above step 782 are not 
met an error response is returned to the communication 
control function (step 788). 
On the other hand, when a result response has been 

30 received, an SNMP response is built up (step 789) and this 
response is sent to the communication control function 100 
(step 790). 

(4) method of managing the collection MIB in the collection 
data base management function 120 
35 The method of carrying out an allocation management of 
a management object and building up a management object 
at the time of responding an MIB value will be explained 
below. 

The collection data base management function 120 inputs 

40 individual information which structure the periodical col- 
lection information from the management range monitoring 
function 110 and stores the information both in the memory 
and in the collection MIB data base 170. 
The individual information includes smglpNodelndex 

45 810 and contents 200 of smglpNodeContext covering an IP 
address 210, a host name 220, a status 230, a ping response 
time 240, SNMP support information 250 and router infor- 
mation 260, as shown in FIG. 27. 
The collection data base management function 120 carries 

50 out management of information in individual information 
units which structure a management object, not in manage- 
ment object unit which is the periodical collection MEB, The 
collection data base management function 120 is structured 
to reduce the volume of data to be exchanged between the 

55 collection data base management function 120 and the 
management range monitoring function 110. by inputting 
only the smglpNodelndex 810 which is the key information 
for specifying an IP node and an information unit to which 
there has been a change, for example, a status 230, from the 

6o management range monitoring function 110. 

When an optional IP node has been deleted from the 
management range of the sub-manager 10, a request for 
deleting the smglpNodelndex 810 is inputted from the 
management range monitoring function 110 and the collec- 

65 tion data base management function 120 changes the flag 
800 from presence" to "absence", thereby managing the IP 
node of the management range. 
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When a reference request to individual information that When a store request has been received, the management 

structure the periodical collection MIB has been received range monitoring function 110 inputs to the collection data 

from the management range monitoring function 110, the base management function 120 the smglpNodcIadex 810 

collection data base management function 120 provides the which is the key information for structuring the periodical 

smglpNodelndex 810 which is the key information and the 5 collection MEB and the contents 200 of the smglpNodeCon- 

requested individual information to the management range text to be updated, and retrieves the corresponding IP node 

monitoring function 110. When mainly the sub-manager 10 by the key information. Then, the collection data base 

has restarted, this information is also provided in order to management function 120 updates the contents 200 of the 

make the relationship between the smglpNodelndex 810 and smglpNodeContext that is held in the memory (step 828). 

the IP address 210 shown in FIG. 27 to be the same as the In the case of adding or deleting an optional IP node to or 

relationship between the same before the restarting of the from the management range of the sub-manager 10, the 

sub-manager 10. collection data base management function 120 updates 

The collection data base management function 120 stores (changes) the flag 800 in FIG, 27 to "presence" or "no" 

the individual information that structure the periodical col- respectively. 

lection MIB in the collection MIB data base 170 in order to Then, the collection data base management function 120 

maintain the above relationship. 15 updates the collection MIB data base 170 (step 829). 

When the sub-manager 10 has received a request for An allocation management can not be carried out to the 

obtaining the periodical collection MIB from the integration management object which expresses the totaling result of the 

manager 50, the collection data base management function collection MIB shown in FIG. 14, so that the MIB value is 

120 receives a request for obtaining the periodical collection simply updated for this management object 

MIB value through the communication control function 100 20 When a reference request has been received, the collec- 

and the sub-manager agent function 140. tion data base management function 120 provides the 

The collection data base management function 120 builds smglpNodelndex 810 which is the key information for 

up a periodical collection MIB value from individual infor- structuring the periodical collection MIB and requested 

mation which structure the periodical collection MIB, and individual information out of the contents of the smgjlpNo- 

returns the result to the integration manager 50 through the 25 deContext are provided to the management range monitar- 

sub-manager agent function 140 and the communication ing function 110 (step 830). Since the allocation manage- 

control function 100. ment is not carried out to the management object which 

The build-up of the periodical collection MIB refers to the expresses the totaled result of the collection MIB shown in 

assembling of each information of the IP address 210 which FIG. 14, the MIB value is simply provided, 

shows one agent and IP node characteristics and IP status, 30 (5) collection and concentration method in the concentration 

the host name 220, the status 230, the response time 240 of function 150 

the ping, the SNMP support information 250 and the router When a TCP connection as shown in FIG. 30 is available, 

information 260, into the smglpNodeContext 200 which is for example, the concentration function 150 concentrates 

one management object as shown in FIG. 27. TCP connections 1000 between IP nodes of the management 

FIG. 28 shows an outline of the operation of the collection 35 range and a TCP connection 1010 between the IP node of the 

data base management function 120. management range and an IP node outside the management 

The collection data base management function 120 loops range. The concentration function 150 does not concentrate 

until an end request has been received (step 820). a TCP connection 1020 between IP nodes outside the 

The data to be received by the collection data base management range. In other words, the concentration func- 

management function 120 (step 821) includes a request for 40 tion 150 concentrates the TCP connections of which at least 

obtaining the periodical collection MTB from the sub- one end is an IP node and this IP node is loaded with the 

manager agent function 140, and a store request and a agent 20. 

reference request from the management range monitoring FIG. 31 shows a format of the index of tcpConnState of 

function 110 t so that a decision is made on what request has the MIB-II and the MTB Yalue which the concentration 

been received (step 821). 45 function 150 collects from the agent of the management 

When an obtain request has been received, the collection range, 

data base management function 120 makes a decision of FIG. 32 shows a real-time collection MTB of the sub- 

whether the request is the get-next operation (step 822), and manager 10 and this shows a format of the index of 

if the request is the get-next operation, the collection data smgSumTcpContext of which MIB value is requested from 

base management function 120 obtains the next assigned 50 the integration manager and the MEB value, 

index (smglpNodelndex 810) (step 823). FIG. 33 shows a relationship of the conversion between 

At the next step 824, a decision is made on the presence FIG. 31 and FIG. 32. The IP address (part 1) 310, the port 

or absence of the index by using the flag 800 in FIG. 27. This number (part 1) 320, the IP address (part 2) 340 and the port 

is mainly for the purpose of confirming the index assigned number (part 2) 350 of the index of smgSumTcpContext 

by the get operation. 55 requested from the integration manager 50 are used for a 

When the index exists, a periodical collection MIB value local IP address 1120, a local TCP port 1130, a remote IP 

to be responded is produced at step 825. If the smglpNo- address 1140 and a remote TCP port 1150 of the index of 

deContext 200 has been requested, the periodical collection tcpConnState 1100. 

MEB is built up. and if a management object which expresses A value 1160 of tcpConnState is set to the status (part 1) 

the total result of the periodical collection MIB shown in 60 of smgSumTcpContext 

FIG. 14 has been requested, this is excluded from the Similarly, the IP address (part 1) 310, the port number 

build-up. (part 1) 320, the IP address (part 2) 330 and the port number 

Then, the collection data base management function 120 (part 2) 340 of the index of smgSumTcpContext are used for 

responds the MTB value to the sub-manager agent function a remote IP address 1120, a remote TCP port 1130, a local 

140 (step 826). If the index does not exist the collection data 65 IP address 1140 and a local TCP port 1150 of the index of 

base management function 120 sends an error response to tcpConnState 1110. A value 1170 of tcpConnState is set to 

the sub-manager agent function 140 (step 827). the status (part 2) 360 of smgSumTcpContext. 
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The service name 370 of smgSumTcpContext is set by When the conditions in the step 1270, the step 1273 and 

obtaining the service name corresponding to the port number the step 1274 are not met, an error is returned (steps 1278, 

(part 1) 320 or the port number (part 2) 350 by referring to 1277 and 1276). 

the /etc/services file. FIG. 38 shows an outline of the get-next processing (step 

FIG. 34 explains the sequence of the index shown in FIG. 5 1204). 

32, and this has a relation with the sequence of the entry 520 At first, a decision is made on the presence or absence of 

of the management range table 500. an assignment of an index (step 1280). If there is an index 

In the IP address (part 1) 310, IP addresses 5206 are assignment, me index is broken down in the same manner as 

arranged in order from the header of the entry. In the port at the step 1250 (step 1281). 

number (part 1) 320 and the port number (part 2) 350, If the index has not been assigned, the next index is 

numbers are arranged in order from the smallest port num- calculated and executed in order to obtain the header index 

ber. In the IP address (part 2) 340, the addresses 520£ are (step 1282). 

arranged in order starting from the entry next to the IP Next, a decision similar to the one at the step 1252 in FEG. 

address (part 1) 310 and the last becomes an IP address 36 is carried out in order to make a decision whether the IP 

outside the management range. addresses exist in the management range or not (step 1284). 

FIG. 35 shows an outline of the main processing of the 15 If the decision is made that only the IP address (part 1) 

concentration function 150. and this processing loops until exists in the management range, get-next issue is executed 

an end request has been received (step 1200). to only the IP address (part 1) (steps 1285 and 1286). 

The concentration function 150 starts the operation when Similarly, if the decision is made that only the IP address 

a request for obtaining the concentration MEB has been (part 2) exists in the management range, get-next issue is 

received from the sub-manager agent function 140 (step 20 executed to only the IP address (part 2) (steps 1287 and 

1201). At first, a decision is made whether the operation is 1288). 

get operation or not (step 1202). If the operation is get If the decision is made that both IP addresses (part 1 and 

operation, get processing is carried out (step 1203), and part 2) exist in the management range, get-next issue is 

get-next processing is carried out in other case (step 1204). executed first to the IP address (part 1) (steps 1289 and 

Next, an error decision is carried out (step 1205). If there 25 1290), and get-next issue is executed to the other address of 

is no error, the concentration function 150 obtains the the connection only when there is no error (steps 1291, 1292 

service name (step 1206) and builds up the contents of and 1293). 

smgSumTcpContext to be responded (step 1207). and An error is returned when none of the IP addresses (part 

responds a result to the sub-manager agent function 140 1 and part 2) is included in the management range (step 

(step 1208). 30 1294). 

When there is an error, the concentration function 150 FIG. 39 shows an outline of the calculation of the next 

returns an error response to the sub-manager agent function index. 

140 (step 1209). At first, a decision is made on the presence or absence of 

FIG. 36 shows an outline of the get processing (the step the assigned index (step 1300). If the assigned index does 
1203). At first, the index shown in FIG. 33 is broken down 35 not exist, the management range table 500 is sequentially 
(step 1250), and the management range table 500 is referred retrieved from the header entry in order to obtain the header 
to (step 1251) in order to make a decision whether the IP index. The IP address 520ft of which status 520# is "Mar- 
address is the one included in the management range or not ginal" or formal" and the SNMP support information is 
(step 1252). "snmp" is set as the new IP address (part 1) 310 (step 1301). 

When only the IP address (part 1) is included in the 40 "0" is set to the port number (part 1) 320. "0.0.0.0" is set 

management range, get issue is executed to only the IP to the IP address (part 2) 340, and "0" is set to the port 

address (part 1) (steps 1253 and 1254). number (part 2) 350. 

Similarly, when only the IP address (part 2) is included in If the index exists at the step 1300, in order to efficiently 

the management range, get issue is executed to only the IP obtain the next index, the management range table 500 is 

address (part 2) (steps 1255 and 1256). 45 sequentially retrieved, and according to the sequence of 

When both IP addresses (part 1 and part 2) are included index shown in FIG. 34. the IP address 5206 which is after 

in the management range, get issue is first executed to the IP the IP address (part 1) 310ft and of which status 520# is 

address (part 1) (steps 1257 and 1258), and only when there "Marginal" or "Normal" and of which SNMP support infor- 

is no error, get issue is executed to the IP address (part 2) mation is "snmp" is set as the new IP address (part 1) 310 

(steps 1259, 1260 and 1261). 50 (step 1305). 

When none of the IP addresses (part 1 and part 2) is FIG. 40 shows an outline of the get-next issue to be 

included in the management range, an error is returned (step executed in FIG. 38. 

1262). In order to efficiently obtain the value of the MIB-IL the 

FIG. 37 shows an outline of the get issue to be executed management range table 500 is referred to and a decision is 

in FIG. 36. 55 made whether the status 520g of the IP address is "Marginal" 

In order to efficiently obtain the value of the MIB-IL the or "NormaT and the SNMP support information 520/ is 

management range table 500 is referred to and a decision is "snmp" or not (step 1310). 

made whether the status 520# of the IP address is "Marginal" When the above conditions are met, the management 

or "Normal" and the SNMP support information 520/ is object identifier shown in FIG. 33 is exchanged (step 1311), 

"snmp" or not (step 1270). 60 and get request is issued (step 1312). 

When the above conditions are met, the management Next, a decision is made to the management object 

object identifier shown in FIG. 33 is exchanged (step 1271), identifier of the obtained result (step 1313). If the obtained 

and get request is issued (step 1272). result is the value of tcpConnState, a decision is made 

Next, a decision is made on the presence or absence of a whether the TCP connection is the one between the IP nodes 

response to the get request and an error decision is made 65 (step 1314). 

(steps 1273 and 1274). When the conditions are met, an If the TCP connection is the one between the IP nodes, the 

obtained result is returned (step 1275). obtained result is returned (step 1315), and if the TCP 
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connection is not for between the IP nodes, get-next issue is Next, the trap management function 160 secures a buffer 

executed again (step 1316). (step 1502), loops the processing during the period of the 

If the obtained result is not tcpConnState at the step 1313, trap relay interval 450 (reference FIG. 15) (step 1503), and 

the next index calculation is executed and a decision is made receives the SNMP trap (step 1504). 

on the presence or absence of the index (steps 1317 and 5 In order to coimim that the received SNPM trap is the one 

1318).Whentenextindexexists,get-nextissueisexecuted from the agent20 of the sub-manager management range, 

(step 1319), when the next index does not exist, an error is Ac top management foncUon 160 refers to the IP address 

returned (step 1320) index 520a in the management range table 500 

When me conditions at ^ ( "?i£Sdved SNPM trap is the one issued by the agent 

processing similar to those at the step 1317 to the step 1320 10 ^ of me su ^ nager management range, the trap manage- 

are earned out. ment function 160 stores the index 520<z and the SNMP trap 

(6) method of reducing SNMP traps in the trap management ^ hflS been received ^ me buffer (steps 1506 and 1507)j 

function 160 ^ management function 160 builds up the sub- 
sraglntermediaryTrap shown in FIG. 10 defines the sub- manager extension trap from the contents of this buffer (step 
manager extension trap to be relayed by the sub-manager 10 15 ^ is SUCS the sub-manager extension trap to the 
in order to reduce the number of the management packets integration manager 50 (step 1509). Then, the trap manage- 
that are used by the SNMP trap, and the extension trap me nt function 160 releases the buffer (step 1510). 
number is "3". Details of the sub-manager 10 which is the main element 
The community name 400 for obtaining the environment of the present invention have been explained above. Accord- 
setting file 180 explained in FIG. 15 is also used when the 20 ing to the present embodiment, there are the following 
sub-manager 10 issues the sub-manager extension trap. The effects when the integration manager 50 refers to the peri- 
trap destination 420 is the other IP address to which the odical collection MIB and real-time collection MIB which 
sub-manager 10 issues the sub-manager extension trap, and are the extension MIB of the sub-manager 10. 
this trap destination 420 can be assigned by a plurality of (1) when the periodical collection MIB is referred to 
number.Thetraprdaymt C rval450ismetimeforstormgthe 25 ™™ J* ^^Ta^^^S "sues the ping 
SNMPtrap which has beenreceived from the agent 20 that GCMP echo request packet) and the SNMP request packet to 
is the management range of the sub-manage? When the thelPnode ofthe sub-nianager management range tod holds 
T , " , , - ... • ■ . the result of the response to these issues as the periodical 
SNMP trap has been received during this period, this is coUectioil ^ ^ h 

one of the sub-manager extension 

arrangedinonesur>inanagerextensiontrapandisrelayedto Mffi . g ^ to ^ m ^fatt response to a 

the integration manager 50. # 30 request from the integration manager 50 for obtaining an 

FIG. 41 shows an outline for converting the SNMP trap, SNMP. 

that has been received by the sub-manager 10 from the agent The periodical collection MIB consists of the manage- 

20 of the management range, into the sub-manager exten- ment object identifier which expresses the characteristics 

sion trap. (index, IP address, host name, IP status, ping response time, 

A format 1400 of smglntennediaryTrap which is the 35 SNMP loading flag. IP router loading flag) of the IP nodes 

sub-manager extension trap is structured by a trap header 0 f the sub-manager management range in 1 (management 

1410 and Variable-bindings 1420. object identifier/IP node) and the management object iden- 

The trap header 1410 is structured by enterprise 1411, tifier which is the individual characteristics totaled by the 

agent-addr 1412, generic-trap 1413, specific-trap 1414 and number of the IP nodes. Accordingly, the network manager 

time-stamp 1415, each of these elements describes sysOb- 40 at the side of the integration manager 50 can confirm, 

jectID of the sub-manager 10, IP addresses "6" and **3" of depending on the application, the structure information and 

the sub-manager 10 and sysUpTime of the sub-manager 10. status information of the sub-manager management range by 

The contents of the received SNMP trap are sequentially referring to the periodical collection MIB of the sub- 
described in the Variable-bindings 1420. manager 10. 

FIG. 42 shows the details for converting the SNMP trap 45 Further, it is possible to reduce the number of the man- 

into the sub-manager extension trap. agement packets between the integration manager 50 and the 

The Variable-bindings 1420 ofthe format 1400 of smgln- sub-manager 10 by the number of the concentration of the 

termediaryTrap is structured by mainly smglpNodelndex periodical collection MIB. 

1430, smgJSnterprise 1431, srngAgentAddr 1432, smgGen- (2) when the real-time collection MIB is referred to 

eridTrap 1433. smgSpecificTrap 1434 and VarBindList so According to the request from the integration manger 50 

1435. to the sub-manager 10 for referring to the real-time coliec- 

The index number 520a of the management range table tion MIB, the management object of each agent is collected, 

500 corresponding to agent-addr 1462 that is the IP address totaled and returned to the integration manager 50 in real 

to which the SNMP trap has been issued is described in the time. Accordingly, it is possible to accept the latest status of 

smglpNodelndex 1430. 55 the sub-manager management range with small resource 

Items of enterprise 1461, the agent-addr 1462, generic- (CPU power and memory capacity) and small number of 

trap 1463 and specific-trap 1464 are described in the smgEn- management packets. It is also possible to reduce time error 

terprise 1431, the smgAgentAddr 1432, the smgGen- between the agents. 

eridTrap 1433 and the smgSpecificTYap 1434 respectively. Further, by managing the TCP collection information of 

Variable-bindings 1470 of the SNMP trap that has been 60 the sub-manager management range as the real-time collec- 

received is described in the VarBindList 1435. tion MIB, it is possible to specify high traffic IP node and 

FIG. 43 shows an outline of the method for reducing the service of the management range of the sub-manager 10 in 

SNMP trap. small operation of the integration manager 50. Further, it is 

At first, the trap management function 160 refers to the possible to reduce the number of management packets 

environment setting file 180 (step 1500) and loops the 65 between the integration manager 50 and the sub-manager 10 

processing until an end request has been received (step as compared with the case where the sub-manager 10 does 

1501). not exist 
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Further, by issuing the sub-manager extension trap, it is 
possible to efficiently transmit to the integration manager 50 
the changes of the sub-manager management range and 
SNMP trap received from the agent. 

In the logical relation diagram shown in FIG. 2, the 5 
hierarchy from the agent to the integration manager is three 
layers. However, the hierarchy is not limited to this accord- 
ing to the present invention. 

We claim: 

1. A hierarchical network management system, compris- 1Q 
ing: 

a plurality of agents, connected to a communication 
network, for managing and controlling information, 
respectively, of a plurality of resources; 

a sub-manager, having a predetermined agent group under x 5 
management, for managing and controlling a portion of 
management objects of said communication network 
through said predetermined agent group; and 

an integration manager for managing and controlling all 
management objects of said hierarchical communica- 2 o 
tion network through said sub-manager, 

said hierarchical network management system using an 
SNMP as a communication protocol between said 
agents and said sub-manager and between said sub- 
manager and said integration manager, respectively, 25 
and 

said hierarchical network management system having 
periodic collecting means for periodically collecting 
within said sub-manager management objects of a 
management range of said sub-manager through said 30 
predetermined agent group, and for posting collected 
information to said integration manager at a reference 
request of said integration manager. 

2. A hierarchical network management system according 

to claim 1, wherein said periodic collecting means periodi- 35 
cally collects management objects including management 
objects which are not loaded with agents or which are not 
started yet. 

3. A hierarchical network management system according 

to claim 1, wherein said periodic collecting means concen- 40 
trates a plurality of information relating to each agent 
managed by a plurality of identifiers and posts said concen- 
trated result to said integration manager, at a reference 
request of said integration manager. 

4. A hierarchical network management system according 45 
to claim 1, further including means in said sub-managers for 
analyzing an SNMP trap received from an agent that exists 

in the management range of said sub-manager and for 
relaying a plurality of SNMP traps to said integration 
manager as a sub-manager single extension trap. 50 

5. A hierarchical network management system according 
to claim 1. further including real-time collecting means in 
said sub-manager for real-time collecting a status of agents 
which belong to the management range of said sub-manager 
and for posting collected information to said integration 55 
manager, at a reference request of said integration manager. 

6. A hierarchical network management system according 
to claim 5, wherein said real-time collecting means selects 
objects for a real-time collection by referring to management 
objects that have been collected by said periodical collecting 60 
means. 

7. A hierarchical network management system according 
to claim 5, wherein said real-time collecting means concen- 
trates a plurality of information relating to each agent 
managed by a plurality of identifiers and posts a concen- 65 
trated result to said integration manager, at a reference 
request from said integration manager. 



8. A hierarchical network management system, compris- 
ing: 

a plurality of agents connected to a first communication 
network; 

a sub-manager connected to said first communication 
network and having a predetermined agent group 
within said plurality of agents under management; 

an integration manager connected to a second communi- 
cation network and having said sub-manager under 
management; and 

a communication path for combining said first and second 
communication networks, 

wherein each of said agents manages and controls man- 
agement objects relating to structure information and 
status information of each of a plurality of resources, 

said sub-manager manages and controls management 
objects of said first communication network through 
said predetermined agent group, 

said integration manager accesses said sub-manager 
through said communication path to thereby manage 
and control a hierarchical communication network 
structures by said first and second communication 
networks through said sub-manager, and 

said sub-manager includes means for functioning as an 
agent to said integration manager and for functioning as 
a manger to said agents, so that a Simple Network 
Management Protocol (SNMP) can be employed as a 
communication protocol between each of said plurality 
of agents and said sub-manager and between said 
sub-manager and said integration manager through said 
communication path. 

9. A hierarchical network management system, compris- 
ing: 

a plurality of lower communication networks; 

a plurality of agents connected to each of said lower 
communication networks; 

a plurality of sub-managers connected to respective ones 
of said lower communication networks, each of said 
plurality of sub-managers having under management a 
predetermined agent group, within the plurality of 
agents connected to a respective one of said lower 
communication networks; 

an integration manager connected to a higher communi- 
cation network and having said plurality of sub- 
managers under management of said integration man- 
ager; and 

a communication path for connecting said plurality of 
lower communication networks and said higher com- 
munication network. 

wherein each of said agents manages and controls man- 
agement objects relating to structure information and 
status information of each of a plurality of resources, 

each of said sub-managers manages and controls man- 
agement objects of a respective one of said lower 
communication networks through the agent group 
under management of said sub-manager, 

said integration manager accesses said sub-managers 
through said communication path to thereby manage 
and control management objects of a hierarchical com- 
munication network structured by said higher commu- 
nication network through said plurality of sub- 
managers, and 

said each of said sub-managers includes means for func- 
tioning as an agent to said integration manager and for 
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functioning as a manager to said agents, so that a 
Simple Network Management Protocol (SNMP) can be 
employed as a communication protocol between each 
of said sub-managers and said integration manager 
through said communication path. 5 

10. A hierarchical network management system according 
to claim 8. wherein said means for functioning as said agent 
to said sub-manager processes a management object of said 
first communication network collected through said agent 
group under management of said sub-agent into a Manage- 10 
ment Information Base (MIB) value for responding to said 
integration manager at an inquiry from said integration 
manager. 

11. A hierarchical network management system according 

to claim 9, wherein said means for functioning as said agent is 
to each of said sub-managers processes a management 
object of said lower communication network collected 
through an agent group under management of said sub-agent 
into a Management Information Base (MIB) value for 
responding to said integration manager at an inquiry from 20 
said integration manager. 

12. A system for hierarchically managing a communica- 
tions network, comprising: 

a plurality of resources; 

25 

a plurality of agents, connected to the communications 
network, for managing management objects of respec- 
tive ones of said plurality of resources; 

a sub-manager for managing, through management of a 
predetermined group of agents within said plurality of 30 
agents, a portion of the management objects of said 
plurality of resources, said sub-manager communicat- 
ing with said plurality of agents using a simple network 
management protocol; 

an integration manager for managing, through said sub- 35 
manager, all of said management objects of said plu- 
rality of resources; 

a communications path connecting said integration man- 
ager to said sub-manager, said integration manager 
communicating with said sub-manager along said path 40 
using a simple network manager protocol; and 

collecting means for periodically collecting within said 
sub-manager, through said predetermined group of 
agents, management objects lying in a management 
range defined for said sub-manager, and for posting to 45 
said integration manager information including said 
collected management objects in response to a refer- 
ence request issued from said integration manager. 

13. The system recited in claim 12, wherein said man- 
agement objects include management objects of structure 50 
information and status information. 

14. A hierarchical network management system, compris- 
ing: 

a first communications network; ^ 

a plurality of agents connected to said first communica- 
tions network; 

a plurality of groups of resources, each of said plurality of 
agents managing management objects of a respective 
group of said plurality of groups of resources; # 

a sub-manager, connected to said first communications 
network, for managing, through management of a pre- 
determined group of agents within said plurality of 
agents, management objects of resources being man- 
aged by said predetermined group of agents, said 
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sub-manager communicating at least with said prede- 
termined group of agents through a simple network 
management protocol; 

a second communications network; 

a communications path for connecting said first and 
second communications networks; 

an integration manager, connected to said second com- 
munications network, for managing said sub-manager, 
said integration manager communicating with said sub- 
manager through said communications path using a 
simple network management protocol and cooperating 
with said sub-manager to manage a hierarchical com- 
munications network which includes said first and 
second communications networks; and 

means, within said sub- manager, for functioning as an 
agent to said integration manager and for functioning as 
a manger to said predetermined group of agents. 

15. The hierarchical network management system recited 
in claim 14, wherein said management objects include 
management objects of structure information and status 
information. 

16. A hierarchical network management system, compris- 
ing: 

a plurality of lower-level communications networks; 

a plurality of sets of agents, each set of agents connected 
to a respective one of said plurality of lower-level 
communications networks, with the agents in each set 
of agents managing management objects of respective 
ones of a plurality of resources; 

a plurality of sub-managers connected to respective ones 
of said lower-level communications networks, each of 
said sub-managers managing, through management of 
a predetermined group of agents within the set of 
agents connected to the lower-level communication 
network to which said each sub-manager is connected, 
management objects being managed by said predeter- 
mined group of agents, each sub-manager communi- 
cating with at Least the predetermined group of agents 
being managed by said each sub-managers using a 
simple network management protocol; 

a higher-level communications network; 

a communications path for connecting said higher-level 
communications network to said plurality of lower- 
level communications networks; 

an integration manager, connected to said higher-level 
communications network, for managing said plurality 
of sub-managers to control management objects being 
managed by the agents in the predetermined groups of 
agents being managed by said sub-managers, said 
integration manager communicating with said plurality 
of sub-managers through said communications path 
using a simple network management protocol; 

wherein each of said plurality of sub-managers includes 
means for functioning as an agent to said integration 
manager and for functioning as a manager to each agent 
in the set of agents being managed by said each of said 
plurality of sub-managers. 

17. The hierarchical network management system recited 
in claim 16, wherein said management objects include 
management objects of structure information and status 
information. 

***** 
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